Synchrone Szenarien mit HTTP, TCP oder benannten Pipes
In diesem Thema werden die Aktivitäten und Übertragungen für verschiedene synchrone Anforderungs-/Antwortszenarien beschrieben. Dabei werden HTTP, TCP oder benannte Pipes mit einem Singlethreadclient verwendet. Weitere Informationen zu Multithreadanforderungen finden Sie unter Asynchrone Szenarien mit HTTP, TCP oder Named-Pipe.
Synchrone Anforderung/Antwort ohne Fehler
In diesem Abschnitt werden die Aktivitäten und Übertragungen für ein gültiges synchrones Anforderungs-/Antwortszenario mit Singlethreadclient beschrieben.
Client
Herstellen einer Verbindung mit Dienstendpunkt
Ein Client wird erstellt und geöffnet. Für jeden dieser Schritte wird die Umgebungsaktivität (A) jeweils auf eine "Konstruktclient"-Aktivität (B) und eine "Offene Client"-Aktivität (C) übertragen. Für jede Aktivität, auf die übertragen wird, wird die Umgebungsaktivität unterbrochen, bis eine Übertragung zurück erfolgt, d. h. bis ServiceModel-Code ausgeführt wird.
Stellen einer Anforderung an einen Dienstendpunkt
Die Umgebungsaktivität wird auf eine "ProcessAction"-Aktivität (D) übertragen. Innerhalb dieser Aktivität wird eine Anforderungsnachricht gesendet, und eine Antwortmeldung wird empfangen. Die Aktivität endet, wenn das Steuerelement zum Benutzercode zurückkehrt. Da dies eine asynchrone Anforderung ist, unterbricht die Umgebungsaktivität, bis das Steuerelement einen Wert zurückgibt.
Schließen einer Verbindung mit Dienstendpunkt
Die Aktivität "Schließen" (I) des Clients wird aus der Umgebungsaktivität erstellt. Dies ist identisch mit "neu" und "geöffnet".
Server
Einrichten eines Diensthosts
Die neuen und geöffneten Aktivitäten (N und O) des ServiceHost werden aus der Umgebungsaktivität (M) erstellt.
Eine Listeneraktivität (P) wird dadurch erstellt, dass ein ServiceHost für jeden Listener geöffnet wird. Die Listeneraktivität wartet darauf, Daten zu empfangen und zu verarbeiten.
Empfangen von Daten durch Übertragung
Wenn Daten durch Übertragung eintreffen, wird eine "ReceiveBytes"-Aktivität (Q) erstellt, wenn sie nicht bereits vorhanden ist, um die empfangenen Daten zu verarbeiten. Diese Aktivität kann für mehrere Nachrichten in einer Verbindung oder einer Warteschlange wiederverwendet werden.
Die ReceiveBytes-Aktivität startet eine ProcessMessage-Aktivität (R), wenn ausreichend Daten vorhanden sind, um eine SOAP-Aktionsnachricht zu erstellen.
Bei der Aktivität R werden die Nachrichtenheader verarbeitet, und der activityID-Header wird überprüft. Wenn dieser Header vorhanden ist, wird die Aktivitäts-ID als ProcessAction-Aktivität festgelegt; andernfalls wird eine neue ID erstellt.
Eine ProcessAction-Aktivität (S) wird erstellt, und es wird auf sie übertragen, wenn der Aufruf verarbeitet wird. Diese Aktivität endet, wenn alle Verarbeitungsschritte bezüglich der eingehenden Nachricht abgeschlossen sind, ggf. einschließlich der Ausführung des Benutzercodes (T) und des Sendens der Antwortnachricht.
Schließen eines Diensthosts
Die Aktivität "Schließen" (Z) des ServiceHost wird aus der Umgebungsaktivität erstellt.
In <A: Name> ist A ein Shortcutsymbol, das die Aktivität im vorangegangenen Text und in Tabelle 3 beschreibt. Name ist ein verkürzter Name der Aktivität.
Wenn propagateActivity=true ist, haben Prozessaktionen des Clients und des Diensts dieselbe Aktivitäts-ID.
Synchrone Anforderung/Antwort mit Fehlern
Der einzige Unterschied zu dem vorherigen Szenario besteht darin, dass eine SOAP-Fehlernachricht als Antwortnachricht zurückgegeben wird. Wenn propagateActivity=true ist, wird die Aktivitäts-ID der Anforderungsnachricht zur SOAP-Fehlernachricht hinzugefügt.
Synchrone unidirektionale Kommunikation ohne Fehler
Der einzige Unterschied zu dem ersten Szenario ist, dass keine Nachricht an den Server zurückgegeben wird. Für HTTP-basierte Protokolle wird immer noch ein Status (gültig oder Fehler) an den Client zurückgegeben. Der Grund dafür ist, dass HTTP das einzige Protokoll mit Anforderungs-Anwort-Semantik ist, das Teil des WCF-Protokollstapels ist. Da TCP-Verarbeitung für WCF ausgeblendet wird, wird keine Bestätigung an den Client gesendet.
Synchrone unidirektionale Kommunikation mit Fehlern
Wenn während der Verarbeitung der Nachricht ein Fehler auftritt (Q oder darüber hinaus), wird keine Benachrichtigung an den Client zurückgegeben. Dies ist identisch mit dem Szenario „Synchrone unidirektionale Kommunikation ohne Fehler“. Sie sollten kein unidirektionales Szenario verwenden, wenn Sie eine Fehlermeldung empfangen möchten.
Duplex
Der Unterschied zu den vorherigen Szenarien besteht darin, dass der Client als Dienst fungiert, wobei er die ReceiveBytes- und die ProcessMessage-Aktivität erstellt, ähnlich wie bei den asynchronen Szenarien.