Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Clientanwendungen müssen WCF-Client- oder Kanalobjekte erstellen, konfigurieren und verwenden, um mit Diensten zu kommunizieren. Im Thema "WCF-Clientübersicht" finden Sie eine Übersicht über die Objekte und Schritte zum Erstellen grundlegender Client- und Kanalobjekte und deren Verwendung.
Dieses Thema enthält ausführliche Informationen zu einigen Problemen mit Clientanwendungen und Client- und Kanalobjekten, die je nach Szenario hilfreich sein können.
Überblick
In diesem Thema werden Verhaltensweisen und Probleme im Zusammenhang mit beschrieben:
Kanal- und Sitzungslebensdauer.
Behandeln von Ausnahmen.
Verstehen von blockierenden Problemen.
Initialisieren von Kanälen interaktiv.
Kanal- und Sitzungslebensdauer
Windows Communication Foundation (WCF)-Anwendungen umfassen zwei Kategorien von Kanälen, Datagramm und sitzungsbasiert.
Ein Datagrammkanal ist ein Kanal, in dem alle Nachrichten nicht korreliert sind. Wenn bei einem Datagrammkanal ein Eingabe- oder Ausgabevorgang fehlschlägt, ist der nächste Vorgang in der Regel nicht betroffen, und derselbe Kanal kann wiederverwendet werden. Daher schlagen Datagrammkanäle in der Regel nicht fehl.
Sitzungsbasierte Kanäle sind hingegen Kanäle mit einer Verbindung zum anderen Endpunkt. Nachrichten in einer Sitzung auf einer Seite werden immer mit derselben Sitzung auf der anderen Seite korreliert. Darüber hinaus müssen beide Teilnehmer einer Sitzung zustimmen, dass die Anforderungen ihrer Unterhaltung erfüllt wurden, damit diese Sitzung als erfolgreich betrachtet wird. Wenn sie sich nicht einigen können, kann der sitzungsbasierte Kanal fehlschlagen.
Öffnen Sie Clients explizit oder implizit, indem Sie den ersten Vorgang aufrufen.
Hinweis
Der Versuch, fehlgeschlagene sitzungsbasierte Kanäle explizit zu erkennen, ist normalerweise nicht sinnvoll, da der Zeitpunkt der Benachrichtigung von der Sitzungsimplementierung abhängt. Da beispielsweise die System.ServiceModel.NetTcpBinding (bei deaktivierter zuverlässiger Sitzung) die Sitzung der TCP-Verbindung anzeigt, wenn Sie das ICommunicationObject.Faulted-Ereignis auf dem Dienst oder dem Client abhören, werden Sie wahrscheinlich bei einem Netzwerkfehler schnell benachrichtigt. Zuverlässige Sitzungen (festgelegt durch Bindungen, in denen die System.ServiceModel.Channels.ReliableSessionBindingElement Aktivierung erfolgt) sind jedoch darauf ausgelegt, Dienste von kleinen Netzwerkfehlern zu isolieren. Wenn die Sitzung innerhalb eines angemessenen Zeitraums wieder eingerichtet werden kann, schlägt die gleiche, für zuverlässige Sitzungen konfigurierte Bindung unter Umständen nicht fehl, bis die Unterbrechung einen längeren Zeitraum andauert.
Die meisten vom System bereitgestellten Bindungen (die Kanäle für die Anwendungsschicht verfügbar machen) verwenden standardmäßig Sitzungen, was jedoch bei System.ServiceModel.BasicHttpBinding nicht der Fall ist. Weitere Informationen finden Sie unter Verwenden von Sitzungen.
Die richtige Verwendung von Sitzungen
Sitzungen bieten eine Möglichkeit, zu wissen, ob der gesamte Nachrichtenaustausch abgeschlossen ist und ob beide Seiten sie als erfolgreich betrachtet haben. Es wird empfohlen, dass eine aufrufende Anwendung den Kanal öffnet, ihn verwendet und den Kanal innerhalb eines try-Blocks schließt. Wenn ein Sitzungskanal geöffnet ist und die ICommunicationObject.Close Methode einmal aufgerufen wird und dieser Aufruf erfolgreich zurückgegeben wird, war die Sitzung erfolgreich. Erfolgreich bedeutet in diesem Fall, dass alle von der Bindung angegebenen Zustellungsgarantien erfüllt wurden und die andere Seite auf dem Kanal nicht ICommunicationObject.Abort vor dem Aufrufen von Close aufgerufen hat.
Der folgende Abschnitt enthält ein Beispiel für diesen Clientansatz.
Behandeln von Ausnahmen
Das Behandeln von Ausnahmen in Clientanwendungen ist einfach. Wird ein Kanal innerhalb eines Try-Blocks geöffnet, verwendet und geschlossen, war die Konversation erfolgreich, wenn keine Ausnahme ausgelöst wird. Wenn eine Ausnahme ausgelöst wird, wird die Unterhaltung in der Regel abgebrochen.
Hinweis
Die Verwendung der using Anweisung (Using in Visual Basic) wird nicht empfohlen. Dies liegt daran, dass das Ende der using Anweisung Ausnahmen verursachen kann, die andere Ausnahmen maskieren können, die Sie möglicherweise kennen müssen. Weitere Informationen finden Sie unter "Schließen und Abbrechen" zum Freigeben von WCF-Clientressourcen.
Das folgende Codebeispiel zeigt das empfohlene Clientmuster unter Verwendung eines Try/Catch-Blocks und nicht der using Anweisung.
using System;
using System.ServiceModel;
using System.ServiceModel.Channels;
using Microsoft.WCF.Documentation;
public class Client
{
public static void Main()
{
// Picks up configuration from the config file.
SampleServiceClient wcfClient = new SampleServiceClient();
try
{
// Making calls.
Console.WriteLine("Enter the greeting to send: ");
string greeting = Console.ReadLine();
Console.WriteLine("The service responded: " + wcfClient.SampleMethod(greeting));
Console.WriteLine("Press ENTER to exit:");
Console.ReadLine();
// Done with service.
wcfClient.Close();
Console.WriteLine("Done!");
}
catch (TimeoutException timeProblem)
{
Console.WriteLine("The service operation timed out. " + timeProblem.Message);
Console.ReadLine();
wcfClient.Abort();
}
catch (FaultException<GreetingFault> greetingFault)
{
Console.WriteLine(greetingFault.Detail.Message);
Console.ReadLine();
wcfClient.Abort();
}
catch (FaultException unknownFault)
{
Console.WriteLine("An unknown exception was received. " + unknownFault.Message);
Console.ReadLine();
wcfClient.Abort();
}
catch (CommunicationException commProblem)
{
Console.WriteLine("There was a communication problem. " + commProblem.Message + commProblem.StackTrace);
Console.ReadLine();
wcfClient.Abort();
}
}
}
Imports System.ServiceModel
Imports System.ServiceModel.Channels
Imports Microsoft.WCF.Documentation
Public Class Client
Public Shared Sub Main()
' Picks up configuration from the config file.
Dim wcfClient As New SampleServiceClient()
Try
' Making calls.
Console.WriteLine("Enter the greeting to send: ")
Dim greeting As String = Console.ReadLine()
Console.WriteLine("The service responded: " & wcfClient.SampleMethod(greeting))
Console.WriteLine("Press ENTER to exit:")
Console.ReadLine()
' Done with service.
wcfClient.Close()
Console.WriteLine("Done!")
Catch timeProblem As TimeoutException
Console.WriteLine("The service operation timed out. " & timeProblem.Message)
Console.ReadLine()
wcfClient.Abort()
Catch greetingFault As FaultException(Of GreetingFault)
Console.WriteLine(greetingFault.Detail.Message)
Console.ReadLine()
wcfClient.Abort()
Catch unknownFault As FaultException
Console.WriteLine("An unknown exception was received. " & unknownFault.Message)
Console.ReadLine()
wcfClient.Abort()
Catch commProblem As CommunicationException
Console.WriteLine("There was a communication problem. " & commProblem.Message + commProblem.StackTrace)
Console.ReadLine()
wcfClient.Abort()
End Try
End Sub
End Class
Hinweis
Das Überprüfen des Werts der ICommunicationObject.State Eigenschaft ist eine Wettlaufbedingung und es wird nicht empfohlen, dies zu tun, um zu bestimmen, ob ein Kanal wiederverwendet oder geschlossen werden soll.
Datagrammkanäle sind nie fehlerhaft, auch wenn Ausnahmen auftreten, wenn sie geschlossen werden. Darüber hinaus lösen Nicht-Duplex-Clients, die sich nicht mithilfe einer sicheren Konversation authentifizieren, in der Regel einen System.ServiceModel.Security.MessageSecurityException aus. Wenn jedoch für den Duplexclient, der eine sichere Konversation verwendet, keine Authentifizierung möglich ist, erhält der Client stattdessen eine System.TimeoutException.
Ausführlichere Informationen zum Arbeiten mit Fehlerinformationen auf Anwendungsebene finden Sie unter Angeben und Behandeln von Fehlern in Verträgen und Diensten. Erwartete Ausnahmen beschreiben erwartete Ausnahmen und zeigen, wie sie behandelt werden. Weitere Informationen zum Behandeln von Fehlern beim Entwickeln von Kanälen finden Sie unter Behandeln von Ausnahmen und Fehlern.
Clientblockierung und Leistung
Wenn eine Anwendung synchron einen Anforderungs-/Antwortvorgang aufruft, wird der Client blockiert, bis ein Rückgabewert empfangen oder eine Ausnahme (wie System.TimeoutException) ausgelöst wird. Dieses Verhalten ähnelt dem lokalen Verhalten. Ruft eine Anwendung synchron einen Vorgang auf einem WCF-Clientobjekt oder -kanal auf, wird der Client erst dann zurückgegeben, wenn die Kanalebene die Daten an das Netzwerk schreiben kann oder bis eine Ausnahme ausgelöst wird. Und während das unidirektionale Nachrichtenaustauschmuster (angegeben durch die Markierung eines Vorgangs, wobei OperationContractAttribute.IsOneWay auf true festgelegt ist) die Reaktionsgeschwindigkeit einiger Clients verbessern kann, können unidirektionale Vorgänge abhängig von der Bindung und den bisher gesendeten Nachrichten auch blockiert werden. Einwegoperationen beziehen sich nur auf den Nachrichtenaustausch, nicht mehr und nicht weniger als das. Weitere Informationen finden Sie unter One-Way Services.
Große Datenblöcke können die Clientverarbeitung unabhängig vom Nachrichtenaustauschmuster verlangsamen. Informationen zur Behandlung dieser Probleme finden Sie unter "Große Daten und Streaming".
Wenn Ihre Anwendung mehr Arbeit ausführen muss, während ein Vorgang abgeschlossen ist, sollten Sie ein asynchrones Methodenpaar auf der Dienstvertragsschnittstelle erstellen, die vom WCF-Client implementiert wird. Am einfachsten können Sie dies tun, um den /async Schalter im ServiceModel Metadata Utility Tool (Svcutil.exe) zu verwenden. Ein Beispiel finden Sie unter How to: Call Service Operations Asynchronously.
Weitere Informationen zur Erhöhung der Clientleistung finden Sie unter Middle-Tier Clientanwendungen.
Dynamisches Auswählen von Anmeldeinformationen durch den Benutzer
Die IInteractiveChannelInitializer Benutzeroberfläche ermöglicht Es Anwendungen, eine Benutzeroberfläche anzuzeigen, über die der Benutzer Anmeldeinformationen auswählen kann, mit denen ein Kanal erstellt wird, bevor die Timeouttimer beginnen.
Anwendungsentwickler können ein eingefügtes IInteractiveChannelInitializer auf zwei Arten nutzen. Die Clientanwendung kann entweder ClientBase<TChannel>.DisplayInitializationUI oder IClientChannel.DisplayInitializationUI (oder eine asynchrone Version) vor dem Öffnen des Kanals (dem expliziten Ansatz) aufrufen oder den ersten Vorgang (den impliziten Ansatz) aufrufen.
Bei Verwendung des impliziten Ansatzes muss die Anwendung den ersten Vorgang für eine ClientBase<TChannel>- oder IClientChannel-Erweiterung aufrufen. Wenn ein anderes Element als der erste Vorgang aufgerufen wird, wird eine Ausnahme ausgelöst.
Wenn Sie den expliziten Ansatz verwenden, muss die Anwendung die folgenden Schritte ausführen:
Rufen Sie entweder ClientBase<TChannel>.DisplayInitializationUI oder IClientChannel.DisplayInitializationUI (oder eine asynchrone Version) auf.
Wenn die Initialisierer zurückgegeben wurden, rufen Sie entweder die Open-Methode für das IClientChannel-Objekt oder für das IClientChannel-Objekt auf, das durch die ClientBase<TChannel>.InnerChannel-Eigenschaft zurückgegeben wird.
Anrufvorgänge.
Es wird empfohlen, dass Produktionsqualitätsanwendungen den Prozess der Benutzeroberfläche steuern, indem sie den expliziten Ansatz übernehmen.
Anwendungen, die den impliziten Ansatz verwenden, rufen die Initialisierer der Benutzeroberfläche auf, aber wenn der Benutzer der Anwendung nicht innerhalb des Send-Timeout-Zeitraums der Bindung reagiert, wird eine Ausnahme ausgelöst, wenn die Benutzeroberfläche zurückkehrt.
Siehe auch
- Duplexdienste
- Anleitung: Zugriff auf Dienste mit One-Way- und Request-Reply-Verträgen
- So greifen Sie auf Dienste mit einem Duplexvertrag zu
- Vorgehensweise: Zugreifen auf einen WSE 3.0-Dienst
- So verwenden Sie die ChannelFactory
- Vorgehensweise: Dienstvorgänge asynchron aufrufen
- Middle-Tier Clientanwendungen