Asynchrone Szenarien mit HTTP, TCP oder benannten Pipes
In diesem Abschnitt werden die Aktivitäten und Übertragungen für verschiedene asynchrone Anforderungs-/Antwortszenarien beschrieben. Dabei werden HTTP, TCP oder benannte Pipes in Multithreadanforderungen verwendet.
Asynchrone Anforderung/Antwort ohne Fehler
In diesem Abschnitt werden die Aktivitäten und Übertragungen für ein asynchrones Anforderungs-/Antwortszenario mit Multithreadclients beschrieben.
Die aufrufende Aktivität ist beendet, wenn beginCall und endCall zurückgegeben werden. Wenn ein Rückruf aufgerufen wird, wird der Rückruf zurückgegeben.
Die aufgerufene Aktivität ist beendet, wenn beginCall und endCall zurückgegeben werden oder bei Rückgabe des Rückrufs, wenn der Rückruf von dieser Aktivität aufgerufen wurde.
Asynchroner Client ohne Rückruf
Weitergabe wird mit HTTP auf beiden Seiten aktiviert
Wenn propagateActivity=true, gibt ProcessMessage an, zu welcher ProcessAction-Aktivität die Übertragung erfolgen soll.
Bei HTTP-basierten Szenarien wird ReceiveBytes zur ersten gesendeten Nachricht aufgerufen und bleibt so lange erhalten wie die Anforderung besteht.
Weitergabe wird mit HTTP auf einer der Seiten deaktiviert
Wenn propagateActivity=false auf einer Seite, gibt ProcessMessage nicht an, zu welcher ProcessAction-Aktivität die Übertragung erfolgen soll. Deshalb wird eine neue temporäre ProcessAction-Aktivität mit einer neuen ID aufgerufen. Wenn die asynchrone Antwort mit der Anforderung im ServiceModel-Code übereinstimmt, kann die Aktivitäts-ID aus dem lokalen Kontext abgerufen werden. Die eigentliche ProcessAction-Aktivität kann mit dieser ID übertragen werden.
Bei HTTP-basierten Szenarien wird ReceiveBytes zur ersten gesendeten Nachricht aufgerufen und bleibt so lange erhalten wie die Anforderung besteht.
Eine ProcessAction-Aktivität wird für einen asynchronen Client erstellt, wenn auf der aufrufenden oder der aufgerufenen Seite propagateActivity=false ist und wenn die Antwortnachricht keinen Action-Header enthält.
Weitergabe wird mit TCP oder benannten Pipes auf beiden Seiten aktiviert
Bei auf benannten Pipes oder TCP basierenden Szenarien wird ReceiveBytes beim Öffnen des Clients aufgerufen und bleibt so lange erhalten wie die Verbindung besteht.
Ähnlich wie in der ersten Abbildung, wenn propagateActivity=true, gibt ProcessMessage an, zu welcher ProcessAction-Aktivität die Übertragung erfolgen soll.
Weitergabe wird mit TCP oder benannten Pipes auf einer der Seiten deaktiviert
Bei auf benannten Pipes oder TCP basierenden Szenarien wird ReceiveBytes beim Öffnen des Clients aufgerufen und bleibt so lange erhalten wie die Verbindung besteht.
Ähnlich wie in der zweiten Abbildung, wenn propagateActivity=false auf einer Seite, gibt ProcessMessage nicht an, zu welcher ProcessAction-Aktivität die Übertragung erfolgen soll. Deshalb wird eine neue temporäre ProcessAction-Aktivität mit einer neuen ID aufgerufen. Wenn die asynchrone Antwort mit der Anforderung im ServiceModel-Code übereinstimmt, kann die Aktivitäts-ID aus dem lokalen Kontext abgerufen werden. Die eigentliche ProcessAction-Aktivität kann mit dieser ID übertragen werden.
Asynchroner Client mit Rückruf
In diesem Szenario werden für den Rückruf und endCall die Aktivitäten G und A' und deren Ein- und Ausgangsübertragung hinzugefügt.
Dieser Abschnitt veranschaulicht lediglich die Verwendung von HTTP mit propagateActivity=true. Die zusätzlichen Aktivitäten und Übertragungen treffen jedoch auch auf die anderen Fälle zu (d. h. propagateActivity=false unter Verwendung von TCP oder Named Pipes).
Der Rückruf erstellt eine neue Aktivität (G), wenn der Client Benutzercode aufruft, um anzugeben, dass Ergebnisse vorliegen. Der Benutzercode ruft dann endCall innerhalb des Rückrufs (siehe Abbildung 5) oder außerhalb des Rückrufs (siehe Abbildung 6) auf Da nicht bekannt ist, aus welcher Benutzeraktivität endCall aufgerufen wird, erhält diese Aktivität die Bezeichnung A’. A' kann mit A identisch sein, muss aber nicht.
Asynchroner Server mit Rückruf
Der Kanalstapel ruft den Client beim Nachrichtenempfang zurück: Ablaufverfolgungen für diese Verarbeitung werden direkt in der ProcessRequest-Aktivität ausgegeben.
Asynchrone Anforderung/Antwort mit Fehlern
Fehlermeldungen werden während endCall empfangen. Davon abgesehen ähneln die Aktivitäten und Übertragungen den vorherigen Szenarien.
Asynchrone unidirektional Kommunikation mit oder ohne Fehler
Keine Antwort oder kein Fehler wird an den Client zurückgegeben.