Con l'uscita del .NET Framework 3.0 nel novembre 2006 si sono aggiunti, basandosi sempre sul CLR e BCL del 2.0, tre nuovi componenti fondamentali: Windows Presentation Foundation, Windows Communication Foundation (WCF) e Windows Workflow Foundation (WF). Questi tre framework erano nuovi sia nell'implementazione sia nell'idea e, sebbene con fatica a causa di una certa complessità di alcuni di essi, si sono dimostrati molto potenti e utili per risolvere tematiche reali.

Nel .NET Framework 3.5, WCF e WF non hanno subito modifiche, ma piuttosto si sono arricchiti di funzionalità e tra queste la possibilità di far dialogare tra di loro i framework, permettendo da una parte di chiamare servizi da workflow, mentre dall'altra di attivarli tramite servizi.

Ecco le principali novità presenti nella nuova versione.

WCF in applicazioni Partial Trust

Nel .NET Framework 3.0 WCF ha un limite molto grosso: richiede i permessi FullTrust per poter funzionare. Sebbene in certe applicazioni questa restrizione sia trascurabile, ne limita comunque i campi d'utilizzo. Nella 3.5 invece, WCF è in grado di funzionare anche in un ambiente Medium Trust, permettendo così di usarlo in applicazioni web o in applicazioni distribuite tramite ClickOnce aventi permessi limitati, come le XBAP di WPF o WinForm distribuite nelle intranet/internet. Si deve far notare, comunque, che ci sono alcune restrizioni e best practices da seguire per poter lavorare in ambienti Partial Trust. A tal proposito si veda questo documento.

Compatibilità con ASP.NET

WCF è una libreria che fa tesoro dell'esperienza maturata da una serie di tecnologie quali remoting, msmq e webservice asmx. Quest'ultimi, nell'implementazione ASP.NET sono rimasti invariati, ma i servizi si sono evoluti, includendo il supporto a sicurezza, crittazione, transazioni e adattandosi a specifiche del consorzio W3C e OASIS. WCF, utilizzabile nelle applicazioni ASP.NET tramite i file .svc, ingloba la maggior parte di queste caratteristiche rendendolo più standard e interoperabile, ma ciò l'ha reso incompatibile con ASP.NET.

In WCF 3.5 invece, è possibile abilitare la compatibilità con ASP.NET, cambiando la pipeline di esecuzione e i messaggi SOAP, semplicemente agendo nel web.config:

<system.serviceModel>
    <serviceHostingEnvironment aspNetCompatibilityEnabled="true" />
</system.serviceModel>

Una volta abilitato il supporto occorre specificare in ogni servizio i requisiti di compatibilità mediante l'attributo AspNetCompatibilityRequirementsMode:

[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Required)]
public class ProductsService : IProducts {
    public ProductGetResponse Get(ProductGetRequest request){
    }
}

Con il supporto ad AJAX di ASP.NET, inoltre, anche gli asmx sono cambiati, supportando non solo richieste SOAP, ma anche semplici richieste HTTP GET e POST, non solo basate su XML, ma anche su JSON (JavaScript Object Notation), una sintassi compatta per rappresentare informazioni ed essere facilmente trattate in JavaScript.

In WCF 3.5 anche i servizi sviluppati con questo framework possono essere consumati da AJAX e ASP.NET con l'ausilio dell'oggetto ScriptManager. Questo è possibile grazie un nuovo binding di nome webHttpBinding che sfrutta la capacità di estensione di WCF per cambiare modalità di encoding, serializzazione e metodo di trasporto.

La realizzazione di servizi utilizzabile da AJAX diventa quindi molto semplice e in gran parte rimane invariata rispetto a come si è sempre proceduto. Il servizio ProductsService.svc definito in precedenza (interfaccia IProducts) può essere utilizzato con una direttiva speciale nel file:

<%@ ServiceHost language=c# Service="ASPItalia.com.Services.ProductsService" %>

Si procede poi col definire nel web.config (in alternativa anche tramite host come è da sempre possibile fare con WCF) il servizio specificando il nuovo binding da utilizzare:

<system.serviceModel>
    <services>
        <service name="ASPItalia.com.Services.ProductsService">
            <endpoint address=""
                behaviorConfiguration="AspNetAjaxBehavior" 
                binding="webHttpBinding"
                contract="ASPItalia.com.Contracts.IProducts" />
        </service>
    </services>
</system.serviceModel>

Il behavior AspNetAjaxBehavior è ovviamente facoltativo, ma permette, oltre alle comuni impostazioni, di abilitare il supporto ai servizi AJAX mediante l'elemento enableWebScript:

<behaviors>
    <endpointBehaviors>
        <behavior name="AspNetAjaxBehavior">
            <enableWebScript />
        </behavior>
     </endpointBehaviors>
</behaviors>

A questo punto allo stesso modo dei servizi asmx, è possibile utilizzare il servizio referenziandolo nella pagina aspx:

<asp:ScriptManager ID="scriptManager" runat="server">  
    <Services>  
        <asp:ServiceReference Path="~/ProductsService.svc" />  
    </Services>    
</asp:ScriptManager>

Da questo momento il motore AJAX di ASP.NET provvede a creare il codice JavaScript proxy per poter chiamare il servizio come i normali asmx. Sono supportati inoltre oggetti complessi (nell'esempio ProductGetResponse) mediante la serializzazione JSON, implementata dalla nuova classe DataContractJsonSerializer (namespace System.ServiceModel.Web) che si affianca al precedente DataContractSerializer e ne sfrutta gli stessi attributi, basandosi quindi su DataContractAttribute e DataMemberAttribute oppure sull'interfaccia ISerializable. Per i limiti e maggiori informazioni sulla serializzazione si veda questa pagina.