Novità in Windows Communication Foundation
In questo argomento vengono illustrate le nuove funzionalità di Windows Communication Foundation (WCF).
Attivazione basata sulla configurazione
In genere, quando si ospita un servizio Windows Communication Foundation (WCF) in Internet Information Services (IIS) o nel servizio Attivazione processo Windows (WAS), è necessario fornire un file con estensione svc. Il file con estensione svc contiene il nome del servizio e una factory di host del servizio personalizzata facoltativa. Quest'ulteriore file comporta un sovraccarico ai fini della gestibilità. Con la funzionalità di attivazione basata sulla configurazione non è più necessario disporre di un file con estensione svc e quindi tale sovraccarico viene evitato. Per ulteriori informazioni, vedere Attivazione basata sulla configurazione in IIS e WAS, Attivazione basata sulla configurazione.
Integrazione di System.Web.Routing
Quando si ospita un servizio Windows Communication Foundation (WCF) in IIS, si inserisce un file con estensione svc nella directory virtuale. Questo file con estensione svc specifica la factory di host del servizio da utilizzare e la classe che implementa il servizio. Quando si inviano richieste al servizio, si specifica il file con estensione svc nell'URI, ad esempio: https://contoso.com/EmployeeServce.svc. Per i programmatori che scrivono servizi REST, questo tipo di URI non è ottimale. Gli URI per i servizi REST indicano una risorsa specifica e in genere non presentano estensioni. La funzionalità di integrazione System.Web.Routing consente di ospitare un servizio WCF che risponde a URI sprovvisti di estensione. Per ulteriori informazioni, vedere Integrazione di System.Web.Routing, Esempio di integrazione di SystemWebRouting.
Supporto delle associazioni a più siti IIS
Se si ospita un servizio Windows Communication Foundation (WCF) in Internet Information Services (IIS) 7.0, potrebbe risultare opportuno fornire più indirizzi di base che utilizzano lo stesso protocollo per lo stesso sito. In questo modo lo stesso servizio può rispondere a diversi URI. Ciò risulta utile se si desidera ospitare un servizio in ascolto su https://www.contoso.com e https://contoso.com. È inoltre utile per creare un servizio che dispone di un indirizzo di base per utenti interni e un indirizzo di base separato per gli utenti esterni. Per ulteriori informazioni, vedere Supporto delle associazioni a più siti IIS,
Servizio di routing
Il servizio di routing è un intermediario SOAP generico che funge da router dei messaggi. La funzionalità principale del servizio di routing consiste nella capacità di indirizzare messaggi in base al relativo contenuto, il che rende possibile l'inoltro di un messaggio a un endpoint client in base a un valore presente all'interno del messaggio stesso, nell'intestazione o nel corpo. Per ulteriori informazioni, vedere Routing, Servizi di routing .
Supporto per WS-Discovery
La funzionalità di individuazione dei servizi consente alle applicazioni client di individuare in modo dinamico gli indirizzi dei servizi in fase di runtime in modo interoperativo utilizzando WS-Discovery. La specifica WS-Discovery delinea i modelli di scambio dei messaggi necessari per eseguire l'individuazione leggera di servizi, tramite multicast (ad hoc) o unicast (utilizzando una risorsa di rete). Per ulteriori informazioni, vedere WCF Discovery, Individuazione (esempi).
Endpoint standard
Gli endpoint standard sono endpoint predefiniti con una o più proprietà (indirizzo, associazione, contratto) fisse. Ad esempio, per tutti gli endpoint di scambio dei metadati IMetadataExchange è impostato come contratto, pertanto non è necessario che lo sviluppatore specifichi il contratto. L'endpoint MEX standard dispone quindi di un contratto IMetadataExchange fisso. Per ulteriori informazioni, vedere Endpoint standard, .
Servizi flusso di lavoro
Con l'introduzione di un set di attività di messaggistica, l'implementazione di flussi di lavoro che inviano e ricevono dati risulta particolarmente semplice. Le attività di messaggistica consentono di creare modelli di scambio dei messaggi complessi che superano le tradizionali chiamate ai metodi in stile RPC o di invio/ricezione. Per ulteriori informazioni, vedere Servizi flusso di lavoro, Services, Services.
Attributo del framework di destinazione
L'attributo dei framework di destinazione viene utilizzato per specificare la versione di .NET Framework di destinazione per un'applicazione ospitata in IIS o WAS. Consente di compilare applicazioni destinate a .NET Framework 2.0, 3.5 o 4 utilizzando Visual Studio. Si tratta di un set di attributi all'interno di un tag <compilation> nel file Web.config di un'applicazione, come illustrato nell'esempio seguente.
<compilation debug="false"
targetFramework="4.0">
<assemblies>
<add assembly="System.Core, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>
<add assembly="System.Xml.Linq, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>
<add assembly="System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
<add assembly="System.Data.DataSetExtensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>
</assemblies>
</compilation>
Se un'applicazione ospitata in IIS o WAS è destinata a una versione di .NET Framework non installata, viene generata un'eccezione che indica il problema. Se il moniker del framework di destinazione non è specificato nel file Web.config dell'applicazione, il valore viene dedotto dalla versione del pool di applicazioni configurata in IIS.
In seguito all'introduzione di questa nuova funzionalità, se si tenta di ospitare un servizio WCF scritto con .NET Framework 3.5 su un computer che esegue .NET Framework 4, potrebbe essere generata un'eccezione ProtocolException con il testo seguente:
Eccezione non gestita: System.ServiceModel.ProtocolException: Il tipo di contenuto text/html; charset=utf-8 del messaggio di risposta non corrisponde al tipo di contenuto del binding (application/soap+xml; charset=utf-8). Se si utilizza un codificatore standard, verificare che il metodo IsContentTypeSupported sia implementato correttamente. I primi 1024 byte della risposta erano: '<html> <head> <title>Il dominio di applicazione o il pool di applicazioni esegue attualmente .NET Framework 4 o versione successiva. Questa condizione può verificarsi se le impostazioni di IIS sono state configurate per la versione 4.0 o successive per l'applicazione Web in questione o se si utilizza il server di sviluppo Web ASP.NET 4.0 o versione successiva. L'elemento <compilation> nel file Web.config per l'applicazione Web non contiene l'attributo 'targetFrameworkMoniker' necessario per questa versione di .NET Framework (ad esempio, '<compilation targetFrameworkMoniker=".NETFramework,Version=v4.0">'). Aggiornare il file Web.config con questo attributo o configurare l'applicazione Web per l'utilizzo di una versione diversa di .NET Framework.</title>...
Questo errore si verifica poiché il dominio applicazione in cui è in esecuzione IIS utilizza .NET Framework 4 e il servizio WCF prevede l'esecuzione con .NET Framework 3.5. Per ulteriori informazioni su come correggere questo problema, vedere Procedura: ospitare un servizio WCF scritto con .NET Framework 3.5 in IIS in esecuzione in .NET Framework 4.
WCF REST
Memorizzazione nella cache
.NET Framework 4 consente di usufruire del meccanismo dichiarativo di memorizzazione nella cache già disponibile in ASP.NET nei servizi WCF REST. In questo modo è possibile memorizzare nella cache le risposte inviate dalle operazioni del servizio WCF REST. Se un utente invia un'operazione HTTP GET al servizio configurato per la memorizzazione nella cache, ASP.NET restituisce la risposta memorizzata nella cache e il metodo del servizio non viene chiamato. Se la cache scade, al successivo tentativo di invio di un'operazione HTTP GET da parte dell'utente, viene chiamato il metodo del servizio e la risposta viene nuovamente memorizzata nella cache.
.NET Framework 4 consente inoltre di implementare la memorizzazione condizionale nella cache di HTTP GET. Negli scenari REST i servizi utilizzano spesso un'operazione HTTP GET condizionale per implementare la memorizzazione intelligente nella cache HTTP, come descritto nella pagina relativa alla specifica HTTP. Per ulteriori informazioni, vedere Supporto di memorizzazione nella cache per servizi HTTP Web WCF, Caching and Automatic Help Page.
Supporto dei formati
Il modello di programmazione HTTP Web di WCF consente di determinare in modo dinamico il formato migliore in cui un'operazione di servizio deve restituire la risposta. È possibile impostare le risposte in modo automatico per XML e JSON in base all'intestazione Accept. Sono state aggiunte interfacce API di supporto per impostare il formato di un'operazione a livello di codice. Per ulteriori informazioni, vedere Formattazione di HTTP Web WCF, Selezione automatica del formato, Selezione avanzata del formato.
Gestione degli errori HTTP REST
La gestione di errori HTTP Web di WCF consente di restituire errori da servizi REST WCF che specificano un codice di stato HTTP, nonché i dettagli sull'errore utilizzando lo stesso formato dell'operazione (ad esempio, XML o JSON). Per ulteriori informazioni, vedere Gestione degli errori HTTP Web WCF, .
Funzionalità di distribuzione
È stata semplificata la configurazione necessaria per eseguire un servizio e sono stati introdotti nuovi endpoint standard per agevolare ulteriormente la configurazione del servizio. Per ulteriori informazioni su sulla nuova configurazione semplificata, vedere Configurazione semplificata. Per ulteriori informazioni su sugli endpoint standard, vedere Endpoint standard.
Quando si ospita un servizio Windows Communication Foundation (WCF) in IIS, si inserisce un file con estensione svc nella directory virtuale. Questo file con estensione svc specifica la factory di host del servizio da utilizzare e la classe che implementa il servizio. Quando si inviano richieste al servizio, si specifica il file con estensione svc nell'URI, ad esempio: https://contoso.com/EmployeeServce.svc. Per i programmatori che scrivono servizi REST, questo tipo di URI non è ottimale. Gli URI per i servizi REST indicano una risorsa specifica e in genere non presentano estensioni. La funzionalità di integrazione di System.Web.Routing consente di ospitare un servizio REST WCF che risponde a URI sprovvisti di estensione. Per ulteriori informazioni, vedere Integrazione di System.Web.Routing.
JavaScript tra domini
JSON Padding (JSONP) è un meccanismo che abilita il supporto di script tra siti nei Web browser. JSONP è progettato sulla base della capacità dei Web browser di caricare script da un sito diverso rispetto a quello da cui è stato recuperato il documento attualmente caricato. Il meccanismo funziona riempiendo il payload JSON con un nome di funzione di callback definito dall'utente, ad esempio:
callback({ “a” = \“b\” });
Nell'esempio precedente viene eseguito il wrapping del payload JSON, {“a” = \”b\”}, in una chiamata di funzione, callback. La funzione di callback deve essere già definita nella pagina Web corrente. Il tipo di contenuto di una risposta JSONP è "application/javascript". Per ulteriori informazioni, vedere JSONP.
Pagina della Guida del servizio WCF REST
.NET Framework versione 4 include una pagina automatica della Guida relativa ai servizi WCF REST. Questa pagina della Guida contiene una descrizione di ogni operazione, formato di richiesta e risposta e schema. Per ulteriori informazioni, vedere Pagina della Guida del servizio HTTP Web WCF, Caching and Automatic Help Page.