Neues in Windows Communication Foundation
In diesem Thema werden die neuen Funktionen von Windows Communication Foundation (WCF) erläutert.
Konfigurationsbasierte Aktivierung
Wenn Sie einen Windows Communication Foundation (WCF)-Dienst unter Internetinformationsdienste (IIS) oder Windows-Prozessaktivierungsdienst (WAS) hosten, müssen Sie normalerweise eine SVC-Datei bereitstellen. Die SVC-Datei enthält den Namen des Diensts und eine optionale benutzerdefinierte Diensthostfactory. Diese Zusatzdatei verursacht einen höheren Verwaltbarkeitsaufwand. Die konfigurationsbasierte Aktivierungsfunktion entfernt die Anforderung einer SVC-Datei, sodass auch der damit verbundene Aufwand entfällt. Weitere Informationen finden Sie unter Konfigurationsbasierte Aktivierung unter IIS und WAS, Konfigurationsbasierte Aktivierung.
System.Web.Routing-Integration
Wenn Sie einen Windows Communication Foundation (WCF)-Dienst in IIS hosten, fügen Sie eine SVC-Datei in das virtuelle Verzeichnis ein. Diese SVC-Datei gibt die zu verwendende Diensthostfactory sowie die Klasse an, die den Dienst implementiert. Beim Senden von Anforderungen an den Dienst geben Sie die SVC-Datei im URI an, z. B.: https://contoso.com/EmployeeServce.svc. Für Programmierer, die REST-Dienste schreiben, ist dieser Typ von URI nicht optimal. URIs für REST-Dienste geben eine bestimmte Ressource an und verfügen normalerweise nicht über Erweiterungen. Mit der System.Web.Routing-Integrationsfunktion können Sie einen WCF-Dienst hosten, der auf URIs ohne Erweiterung reagiert. Weitere Informationen finden Sie unter System.Web.Routing-Integration, SystemWebRouting-Integrationsbeispiel.
Unterstützung für mehrere IIS-Sitebindungen
Beim Hosten eines Windows Communication Foundation (WCF)-Diensts unter Internetinformationsdienste (IIS) 7.0 sollten Sie mehrere Basisadressen bereitstellen, die das gleiche Protokoll auf der gleichen Website verwenden. Auf diese Weise kann ein Dienst auf unterschiedliche URIs reagieren. Dies ist nützlich, wenn Sie einen Dienst hosten möchten, der "https://www.contoso.com" und "https://contoso.com" überwacht. Es ist auch hilfreich, einen Dienst zu erstellen, der über eine Basisadresse für interne Benutzer und eine separate Basisadresse für externe Benutzer verfügt. Weitere Informationen finden Sie unter Unterstützen mehrerer IIS-Sitebindungen,
Routingdienst
Der Routingdienst ist ein generischer SOAP-Vermittler, der als Nachrichtenrouter fungiert. Die Kernfunktion des Routingdiensts ist die Fähigkeit, Nachrichten basierend auf dem Nachrichtinhalt weiterzuleiten. So können Nachrichten anhand eines Werts innerhalb der Nachricht selbst (im Header oder im Text) an einen Clientendpunkt weitergeleitet werden. Weitere Informationen finden Sie unter Routing, Routingdienste .
Unterstützung für WS-Suche
Die Dienstsuchfunktion ermöglicht Clientanwendungen das dynamische Suchen nach Dienstadressen zur Laufzeit auf interoperable Weise mithilfe der WS-Suche. Die Spezifikation der WS-Suche gibt die Muster für den Nachrichtenaustausch (Message Exchange Patterns, MEPs) vor, die sowohl für Multicast-Vorgänge (Ad-hoc) als auch für Unicast-Vorgänge (unter Verwendung einer Netzwerkressource) zum Durchführen von Lightweight-Suchen nach Diensten erforderlich sind. Weitere Informationen finden Sie unter WCF-Suche, Suche (Beispiele).
Standardendpunkte
Standardendpunkte sind vordefinierte Endpunkte, für die eine oder mehrere Eigenschaften (Adresse, Bindung, Vertrag) fest vorgegeben sind. Alle Metadatenaustausch-Endpunkte geben z. B. IMetadataExchange als Vertrag an, damit Entwickler den Vertrag nicht angeben müssen. Der MEX-Standardendpunkt verfügt daher über einen festen IMetadataExchange-Vertrag. Weitere Informationen finden Sie unter Standardendpunkte, .
Workflowdienste
Dank der Einführung einer Gruppe von Messagingaktivitäten ist es einfacher als jemals zuvor, Workflows zu implementieren, die Daten senden und empfangen. Mit diesen Messagingaktivitäten können Sie komplexe Nachrichtenaustauschmuster modellieren, die für Methodenaufrufe andere Vorgehensweisen als das herkömmliche Senden/Empfangen oder als den RPC-Stil verwenden. Weitere Informationen finden Sie unter Workflowdienste, Services, Services.
Zielframeworkattribut
Das Zielframeworkattribut wird verwendet, um die Version von .NET Framework anzugeben, auf die eine in IIS oder WAS gehostete Anwendung abzielt. Sie können mithilfe von Visual Studio Anwendungen erstellen, die auf .NET Framework 2.0, 3.5 oder 4 abzielen. Es handelt sich um einen Attributsatz innerhalb eines <compilation>-Tags in der Web.config-Datei einer Anwendung, wie im folgenden Beispiel gezeigt.
<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>
Wenn eine in IIS oder WAS gehostete Anwendung auf eine nicht installierte Version von .NET Framework abzielt, wird eine Ausnahme ausgelöst, die auf das Problem hinweist. Wenn der Zielframeworkmoniker nicht in der Web.config-Datei der Anwendung angegeben ist, wird der Wert von der in IIS konfigurierten Anwendungspoolversion abgeleitet.
Wenn Sie versuchen, einen WCF-Dienst zu hosten, der mit .NET Framework 3.5 geschrieben wurde und auf einem Computer mit .NET Framework 4 ausgeführt wird, wird aufgrund dieser neuen Funktion ggf. eine ProtocolException mit dem folgenden Text ausgegeben:
Unhandled Exception: System.ServiceModel.ProtocolException: The content type text/html; charset=utf-8 of the response message does not match the content type of the binding (application/soap+xml; charset=utf-8). If using a custom encoder, be sure that the IsContentTypeSupported method is implemented properly. The first 1024 bytes of the response were: '<html> <head> <title>The application domain or application pool is currently running version 4 or later of the .NET Framework. This can occur if IIS settings have been set to 4.0 or later for this Web application, or if you are using version 4.0 or later of the ASP.NET Web Development Server. The <compilation> element in the Web.config file for this Web application does not contain the required'targetFrameworkMoniker' attribute for this version of the .NET Framework (for example, '<compilation targetFrameworkMoniker=".NETFramework,Version=v4.0">'). Update the Web.config file with this attribute, or configure the Web application to use a different version of the .NET Framework.</title>...
Dieser Fehler tritt auf, weil die Anwendungsdomäne, unter der IIS ausgeführt wird, .NET Framework 4 ausführt und der WCF-Dienst die Ausführung unter .NET Framework 3.5 erwartet. Weitere Informationen über zur Behebung dieses Problems finden Sie unter Vorgehensweise: Hosten eines WCF-Diensts, der mit .NET Framework 3.5 unter IIS geschrieben wurde und unter .NET Framework 4 ausgeführt wird.
WCF REST
Zwischenspeichern
Mithilfe von .NET Framework 4 können Sie den Mechanismus für das deklarative Zwischenspeichern nutzen, der unter ASP.NET bereits in den WCF REST-Diensten verfügbar ist. Auf diese Weise können Sie Antworten der WCF REST-Dienstvorgänge zwischenspeichern. Wenn ein Benutzer HTTP GET an den Dienst sendet, der zum Zwischenspeichern konfiguriert ist, sendet ASP.NET die zwischengespeicherte Antwort zurück, und die Dienstmethode wird nicht aufgerufen. Wenn der Cache abgelaufen ist, wird beim nächsten Senden eines HTTP GET durch einen Benutzer die Dienstmethode aufgerufen und die Antwort erneut zwischengespeichert.
Mit .NET Framework 4 können Sie auch das bedingte HTTP GET-Zwischenspeichern implementieren. In REST-Szenarien wird bedingtes HTTP GET häufig von Diensten verwendet, um die intelligente HTTP-Zwischenspeicherung zu implementieren. Dies ist in der HTTP-Spezifikation beschrieben. Weitere Informationen finden Sie unter Cacheunterstützung für WCF-Web-HTTP-Dienste, Caching and Automatic Help Page.
Formatunterstützung
Mit dem WCF-Web-HTTP-Programmiermodell können Sie auf dynamische Weise das beste Format für einen Dienstvorgang ermitteln, in dem dieser seine Antwort zurückgibt. Antworten können basierend auf dem Accept-Header automatisch für XML und JSON festgelegt werden. Hilfs-APIs wurden hinzugefügt, um das Format eines Vorgangs programmgesteuert festlegen zu können. Weitere Informationen finden Sie unter WCF-Web-HTTP-Formatierung, Automatische Formatauswahl, Erweiterte Formatauswahl.
HTTP REST-Fehlerbehandlung
Die WCF-Web-HTTP-Fehlerbehandlung ermöglicht es Ihnen, Fehler von WCF REST-Diensten zurückzugeben, die einen HTTP-Statuscode angeben, sowie Fehlerdetails im gleichen Format wie der Vorgang (z. B. XML oder JSON) zurückzugeben. Weitere Informationen finden Sie unter WCF-Web-HTTP-Fehlerbehandlung, .
Bereitstellungsfunktionen
Die zum Ausführen eines Diensts erforderliche Konfiguration wurde vereinfacht, und es wurden neue Standardendpunkte eingeführt, um die Dienstkonfiguration weiter zu vereinfachen. Weitere Informationen über zur neuen vereinfachten Konfiguration finden Sie unter Vereinfachte Konfiguration. Weitere Informationen über zu Standardendpunkten finden Sie unter Standardendpunkte.
Wenn Sie einen Windows Communication Foundation (WCF)-Dienst in IIS hosten, fügen Sie eine SVC-Datei in das virtuelle Verzeichnis ein. Diese SVC-Datei gibt die zu verwendende Diensthostfactory sowie die Klasse an, die den Dienst implementiert. Beim Senden von Anforderungen an den Dienst geben Sie die SVC-Datei im URI an, z. B.: https://contoso.com/EmployeeServce.svc. Für Programmierer, die REST-Dienste schreiben, ist dieser Typ von URI nicht optimal. URIs für REST-Dienste geben eine bestimmte Ressource an und verfügen normalerweise nicht über Erweiterungen. Mit der System.Web.Routing-Integrationsfunktion können Sie einen WCF REST-Dienst hosten, der auf URIs ohne Erweiterung reagiert. Weitere Informationen finden Sie unter System.Web.Routing-Integration.
Domänenübergreifendes JavaScript
JSON mit Padding (JSONP) ist ein Mechanismus, der in Webbrowsern die siteübergreifende Skriptunterstützung ermöglicht. Das Design von JSONP basiert darauf, dass Webbrowser Skripts von einer Website laden können, die sich von der Website unterscheidet, von der das momentan geladene Dokument abgerufen wurde. Der Mechanismus funktioniert, indem die JSON-Nutzlast als Padding den Namen einer benutzerdefinierten Rückruffunktion erhält. Beispiel:
callback({ “a” = \“b\” });
Im obigen Beispiel wird die JSON-Nutzlast, {“a” = \”b\”}, mit einem Funktionsaufruf, callback, als Wrapper versehen. Die Rückruffunktion muss auf der aktuellen Webseite bereits definiert sein. Der Inhaltstyp einer JSONP-Antwort lautet "application/javascript". Weitere Informationen finden Sie unter JSONP.
Hilfeseite zum WCF REST-Dienst
.NET Framework, Version 4 stellt eine automatische Hilfeseite für WCF REST-Dienste dar. Auf dieser Hilfeseite sind Beschreibungen der einzelnen Vorgänge, Anforderungs- und Antwortformate sowie Schemas aufgeführt. Weitere Informationen finden Sie unter Hilfeseite zum WCF-Web-HTTP-Dienst, Caching and Automatic Help Page.