Asynchrones Kommunizieren mit XML-Webdiensten
Dieses Thema bezieht sich auf eine veraltete Technologie. XML-Webdienste und XML-Webdienstclients sollten nun mithilfe der folgenden Technologie erstellt werden: Windows Communication Foundation.
Die asynchrone Kommunikation mit einem Webdienst erfolgt entsprechend den beiden, von .NET Framework definierten Entwurfsmustern für einen asynchronen Methodenaufruf. Bevor Sie sich jedoch mit den Einzelheiten beschäftigen, müssen Sie wissen, dass ein Webdienst zur Verarbeitung asynchroner Anforderungen nicht auf eine bestimmte Weise geschrieben sein muss, um asynchron aufgerufen zu werden.
Wsdl.exe und das asynchrone Entwurfsmuster von .NET Framework
Wenn das Web Services Description Language-Tool (Wsdl.exe) eine Clientproxyklasse für den Zugriff auf einen angegebenen Webdienst generiert, stellt es der Proxyklasse zwei Mechanismen für eine asynchrone Kommunikation mit jeder Webdienstmethode bereit. Der erste Mechanismus ist das Begin/End-Muster. Der zweite Mechanismus ist das ereignisgesteuerte asynchrone Programmiermuster, das in Version 2.0 von .NET Framework verfügbar ist. Eine kurze Beschreibung zur Verwendung der Muster mit Webdiensten finden Sie in den folgenden Abschnitten. Ausführliche Informationen über beide Muster finden Sie unter Asynchronous Programming Design Patterns.
Das Begin/End-Aufrufmuster
Wsdl.exe erstellt automatisch drei Methoden für jeden Vorgang (Webdienstmethode in ASP.NET), die im Webdienst veröffentlicht wird. Eine Methode ist für den synchronen Zugriff, die anderen zwei sind für den asynchronen Zugriff. Dies ist auch dann der Fall, wenn es nur eine synchrone Implementierung der Webdienstmethode gibt. In der folgenden Tabelle werden die drei Methoden beschrieben.
| Methodenname in Proxyklasse | Beschreibung |
|---|---|
<NameOfWebServiceMethod> |
Sendet synchron eine Nachricht für die Webdienstmethode mit dem Namen <NameOfWebServiceMethod>. |
Begin<NameOfWebServiceMethod> |
Beginnt die asynchrone Nachrichtenkommunikation mit einer Webdienstmethode mit dem Namen <NameOfWebServiceMethod>. Der Client weist die Begin-Methode an, mit der Verarbeitung des Dienstaufrufs zu beginnen, gleich darauf aber wieder zurückzukehren. Der Rückgabewert ist nicht der von der Webdienstmethode angegebene Datentyp, sondern ein Typ, der die IAsyncResult-Schnittstelle implementiert. |
End<NameOfWebServiceMethod> |
Beendet eine asynchrone Nachrichtenkommunikation mit einer Webdienstmethode mit dem Namen <NameOfWebServiceMethod> und gibt einen Wert zurück, der das Ergebnis des Aufrufs einer Webdienstmethode ist. |
Die Begin-Methode und die End-Methode entsprechen der Namenskonvention für das asynchrone Entwurfsmuster von .NET Framework . Das Entwurfsmuster gibt an, dass es für jede synchrone Methode zwei als solche bezeichnete asynchrone Methoden gibt.
Nehmen Sie zum Beispiel eine Webdienstklasse PrimeFactorizer an, die eine nach Primfaktoren suchende Webdienstmethode mit folgender Signatur besitzt:
public long[] Factorize(long factorizableNum)
Abhängig von der Eingabe kann es relativ lange dauern, bis die Verarbeitung einer solchen Methode abgeschlossen ist. Sie ist folglich ein gutes Beispiel dafür, wann der Webdienstclient die Webdienstmethode asynchron aufrufen sollte.
Wenn Wsdl.exe diesen Webdienst als Eingabe zum Generieren von Clientproxycode (mit der ?wsdl-Abfragezeichenfolge für einen ASP.NET-Webdienst) verwenden würde, dann würden Methoden mit den folgenden Signaturen generiert:
public long[] Factorize(long factorizableNum)
public System.IAsyncResult BeginFactorize(long factorizableNum, System.AsyncCallback callback, object asyncState)
public long[] EndFactorize(System.IAsyncResult asyncResult)
Implementieren eines Webdienstclients, der einen asynchronen Methodenaufruf mit dem Begin/End-Muster ausführt
Woher weiß ein Client, wann die End-Methode aufgerufen werden muss? Gemäß der .NET Framework-Definition gibt es zwei Techniken zum Implementieren eines Clients, der dies bestimmen kann:
Wait-Technik: Verwenden Sie eine der Methoden der WaitHandle-Klasse, damit der Client auf den Abschluss der Methode wartet.
Rückruftechnik: Übergeben Sie eine Rückruffunktion an die Begin-Methode, die anschließend zum Abrufen der Ergebnisse aufgerufen wird, wenn die Methode die Verarbeitung beendet hat.
Hinweis: Die gesendeten und empfangenen SOAP-Nachrichten sind mit den SOAP-Nachrichten identisch, die über die synchrone Proxymethode generiert werden, und zwar unabhängig davon, welche der beiden Techniken von einem Client für die asynchrone Kommunikation mit einem Webdienst gewählt wird. Das bedeutet, dass nur eine SOAP-Anforderung und SOAP-Antwort über das Netzwerk gesendet und empfangen wird. Die Proxyklasse erreicht dies, indem sie die SOAP-Antwort mit einem anderen Thread als dem Thread verarbeitet, den der Client zum Aufrufen der Begin-Methode verwendet hat. Daher kann der Client auf seinem Thread andere Aufgaben erledigen, während die Proxyklasse den Empfang und die Verarbeitung der SOAP-Antwort handhabt.
Wait-Technik mit dem Begin/End-Muster
Die WaitHandle-Klasse implementiert Methoden, die das Warten auf zu signalisierende Synchronisierungsobjekte unterstützen: WaitOne, WaitAny und WaitAll. Die Signalisierung eines Synchronisierungsobjekts ist ein Hinweis darauf, dass Threads, die auf die angegebene Ressource warten, auf die Ressource zugreifen können. Der Webdienstclient greift über die AsyncWaitHandle-Eigenschaft des IAsyncResult-Objekts, das von der Begin-Methode zurückgegeben wird, auf ein WaitHandle-Objekt zu.
Ein Beispiel für diese Technik finden Sie unter Vorgehensweise: Implementieren eines asynchronen Webdienstclients mithilfe der Wait-Technik.
Rückruftechnik mit dem Begin/End-Muster
Bei der Rückruftechnik implementiert eine Rückruffunktion den AsyncCallback-Delegaten, der die Signatur durchsetzt:
public void MethodName(IAsyncResult ar)
Ein Beispiel für diese Technik finden Sie unter Vorgehensweise: Implementieren eines asynchronen Webdienstclients mithilfe der Rückruftechnik.
Wenn der Rückruf synchronisierten/Threadaffinitätskontext erfordert, wird er über die Infrastruktur des Kontextverteilers weitergeleitet. Anders ausgedrückt bedeutet dies, dass der Rückruf in Bezug auf seinen Aufrufer für solche Kontexte asynchron ausgeführt werden könnte. Das ist genau die Semantik des unidirektionalen Qualifizierers für Methodensignaturen. Das bedeutet, dass jeder dieser Methodenaufrufe in Bezug auf den Aufrufer synchron oder asynchron ausgeführt werden könnte, und der Aufrufer keine Voraussagen über die Beendigung eines solchen Aufrufs machen kann, wenn die Ausführungssteuerung zurückgegeben wird.
Ein Aufruf der End-Methode vor Abschluss des asynchronen Vorgangs blockiert den Aufrufer. Das Verhalten für ein zweites Aufrufen der Methode mit dem gleichen, von der Begin-Methode zurückgegebenen IAsyncResult ist nicht definiert.
Asynchrone Webdienstclients, die das ereignisgesteuerte asynchrone Muster verwenden
In Multithreaded Programming with the Event-based Asynchronous Pattern wird ein neues Programmierungsmodell vorgestellt, das Rückrufe mithilfe von Ereignissen behandelt. Dadurch können Sie leichter Multithreadanwendungen erstellen, ohne selbst komplexen Multithreadcode implementieren zu müssen. Eine Übersicht über das neue ereignisgesteuerte asynchrone Modell finden Sie unter Event-based Asynchronous Pattern Overview. Nähere Informationen zu Clientimplementierungen mithilfe des neuen Modells finden Sie unter How to: Implement a Client of the Event-based Asynchronous Pattern.
Informationen zum Erstellen eines Webdiensts mithilfe des ereignisgesteuerten Musters finden Sie unter Vorgehensweise: Implementieren eines ereignisgesteuerten asynchronen Webdienstclients mit ASP.NET 2.0.
Siehe auch
Aufgaben
Vorgehensweise: Implementieren eines asynchronen Webdienstclients mithilfe der Wait-Technik
Vorgehensweise: Implementieren eines asynchronen Webdienstclients mithilfe der Rückruftechnik
Vorgehensweise: Ausführen eines asynchronen Aufrufs von einem Webdienstclient
Konzepte
Erstellen von XML-Webdienstclients
Entwurfsrichtlinien für mit ASP.NET erstellte XML-Webdienste