Webdienst-Endpunkte, die auf WSDL-Dateien basieren

  • Artikel

Aktualisiert: November 2007

Sie können einen vertragsgesteuerten Ansatz verwenden, um das Dienstverhalten zu definieren. Für diese Aufgabe können Sie Webdienst-Anbieterendpunkte aus WSDL (Web Services Description Language)-Dateien erstellen. Sie können aber auch vorhandene Webdienst-Anbieterendpunkte an WSDL-Dateien anpassen.

Hinweis:

Verwenden Sie DISCO-Dateien für diese Aufgaben. Diese Version unterstützt ausschließlich WSDL-Dateien mit einzelnen WSDL-Bindungen und DISCO-Dateien, die auf einzelne Webdienste verweisen. Weitere Informationen finden Sie unter Kommunikation zwischen Anwendungen.

Weitere Informationen finden Sie in den folgenden Abschnitten:

  • Creating Web Service Endpoints from WSDL Files

  • Conforming Web Service Endpoints to WSDL Files

  • Web Service Endpoints Based on WSDL Files

  • Custom Types Referenced in Operation Signatures

Weitere Informationen zu vertragsgesteuerten Dienstentwürfen finden Sie auf der Seite Contract First Web Services Interoperability bei MSDN Online unter https://go.microsoft.com/fwlink/?LinkId=49584.

Erstellen von Webdienst-Endpunkten aus WSDL-Dateien

Sie können WSDL-basierte Endpunkte in ASP.NET-Anwendungen und Systemen erstellen. Dieser Endpunkt wird in der Anwendung oder im System angezeigt. Darin werden Vorgangssignaturen eingefügt, auf die in der WSDL-Datei verwiesen wird. Diese Vorgangssignaturen werden auch in der Klassendatei des Webdiensts angezeigt, wenn die zugehörige Anwendung bereits implementiert ist. Zusätzliche Klassendateien werden ebenfalls im Projekt der Anwendung angezeigt, wenn diese Signaturen auf benutzerdefinierte Typen verweisen. Weitere Informationen finden Sie unter Custom Types Referenced in Operation Signatures.

Hinweis:

Es können nur Anwendungen und keine Systeme implementiert werden.

Das Erstellen eines Webdienst-Anbieterendpunkts aus einer WSDL-Datei entspricht dem Verwenden des Befehlszeilendienstprogramms Wsdl.exe mit der Option /server. Weitere Informationen finden Sie in folgenden Abschnitten:

Anpassen von Webdienst-Endpunkten an WSDL-Dateien

Sie können vorhandene Webdienst-Anbieterendpunkte an WSDL-Dateien anpassen. Dabei werden vorhandene Vorgangssignaturen hinzugefügt oder geändert, sodass sie mit der WSDL-Datei übereinstimmen. Diese Aktion kann sich auch auf Vorgangssignaturen und Typnamen in Code auswirken, wenn die zugehörige Anwendung bereits implementiert ist. Geschachtelte Typen innerhalb von Datasets werden jedoch nicht angepasst.

Hinweis:

Wenn ein Endpunkt des Members eines Systems angepasst wird, wird eigentlich die zugrunde liegende Endpunktdefinition angepasst. Damit wird die Verwendung dieser Definition in anderen Systemen geändert.

Methodentextcode wird zwar nicht geändert, Änderungen an Vorgangssignaturen und Typennamen können jedoch dazu führen, dass sich Methodentextcode nicht mehr kompilieren lässt. Deshalb empfiehlt es sich, den Code zu überprüfen. Ermitteln Sie, welche Änderungen zur Behebung von Compilerfehlern erforderlich sind. Weitere Informationen finden Sie unter Codeänderungen nach dem Anpassen von Webdienst-Endpunkten an WSDL-Dateien.

Webdienst-Endpunkte, die auf WSDL-Dateien basieren

Eine WSDL-Datei enthält die Anforderungen für die Bereitstellung und Verwendung eines Webdiensts. Sie fungiert als Vertrag zwischen Anbieter und Consumer. Webdienst-Endpunkte, die auf derselben Version einer WSDL-Datei basieren, können ausgetauscht werden. Weitere Informationen finden Sie unter Ersetzen von Webdienst-Endpunkten.

Die WSDL-Bindungsdefinition in einer WSDL-Datei beschreibt die von einem Webdienst angebotenen Vorgänge. Der Webdienst-Anbieterendpunkt stellt diese WSDL-Bindung dar. Wenn die zugehörige ASP.NET-Anwendung die Generierung der WSDL-Datei zulässt, generiert Visual Studio eine neue WSDL-Datei für jeden Webdienst in dieser Anwendung (sobald die Anwendung implementiert wird). Visual Studio verwendet die WSDL-Datei auch zum Generieren von Webverweisen für zugehörige Webdienst-Consumeranwendungen (sobald sie implementiert werden). Weitere Informationen finden Sie unter Gewusst wie: Steuern der Generierung von WSDL-Dateien für ASP.NET-Webdienste.

Nachdem die WSDL-Datei für einen Webdienst veröffentlicht wurde, werden alle Änderungen an der Webdienstdefinition wie eine neue WSDL-Bindung behandelt.

Tipp:

Wenn Sie die Webdienstdefinition ändern, ändern Sie auch den WSDL-Bindungsnamen und/oder den WSDL-Bindungsnamespace. Wenn Sie eine Webdienstdefinition ändern, ohne den zugehörigen WSDL-Bindungsnamen oder -namespace zu ändern, gibt es keinen Hinweis darauf, dass der Webdienst möglicherweise nicht mehr mit verbundenen oder ehemals verbundenen Anwendungen kompatibel ist. Der Standardwert des WSDL-Dienstnamens und des WSDL-Bindungsnamens lautet "WebServiceN", wobei "N" eine Ordinalzahl darstellt. Wenn Sie aber nach dem Implementieren der Anwendung den WSDL-Bindungsnamen in der Klassendatei des Webdiensts löschen, wird der Standardwert in "WebServiceNSoap" geändert. Der Standardwert für den WSDL-Dienstnamespace und den WSDL-Bindungsnamespace lautet "http://tempuri.org". Die Eigenschaften für die WSDL-Dienstbeschreibung und den WSDL-Bindungsspeicherort verfügen über keine Standardwerte. Der Standardwert für den WSDL-Bindungsnamen ist "WebServiceN".

Wenn Sie den WSDL-Bindungsnamen oder -Bindungsnamespace auf einem nicht implementierten Anbieterendpunkt für einen Webdienst ändern, werden die zugehörigen Eigenschaften verbundener und nicht implementierter Consumerendpunkte entweder automatisch oder beim nächsten Verbinden aktualisiert. Wenn Sie diese Eigenschaften allerdings auf einem implementierten Anbieterendpunkt für einen Webdienst ändern, werden die verbundenen und implementierten Consumerendpunkte für den Webdienst möglicherweise nicht sofort aktualisiert. Sie können diese Eigenschaften für die Consumerendpunkte aber manuell aktualisieren.

Benutzerdefinierte Typen, auf die in Vorgangssignaturen verwiesen wird

Die Vorgangssignaturen in einem Webdienst-Endpunkt können auf CLR-Klassen verweisen, die die XML-Serialisierung komplexer XML-Typen behandeln, auf die wiederum in der WSDL-Datei oder zugehörigen XML-Schemadateien verwiesen wird. Wenn die zugehörige Anwendung noch nicht implementiert ist, generiert Visual Studio nach der Implementierung Codedateien für diese Klassen. Diese Dateien werden zusammen mit dem entsprechenden Webdienst und den entsprechenden Anwendungsprojektdateien generiert. Wenn die Anwendung bereits implementiert ist, werden dem vorhandenen Projekt Codedateien für diese Klassen hinzugefügt. Weitere Informationen finden Sie unter Übersicht über ASP.NET-Anwendungen in Anwendungsdiagrammen.

Hinweis:

Wenn Sie einen WSDL-basierten Webdienst-Endpunkt in eine andere Anwendung kopieren, kopiert Visual Studio nur die Vorgangssignaturen. Wenn die Zielanwendung bereits implementiert ist, werden die Codedateien für zusätzliche CLR-Klassen nicht kopiert. Wenn die Zielanwendung noch nicht implementiert ist, werden nach der Implementierung keine Codedateien für diese Klassen generiert. Diese Situation kann vermieden werden, indem Sie Endpunkte aus der WSDL- oder DISCO-Datei erstellen, die für die zu kopierenden Endpunkte verwendet wird.

In einigen XML-Schemas sind zusätzliche Serialisierungsattribute für die Webdienstklasse und die Klassen für die Datenserialisierung erforderlich, damit der XML-Code richtig formatiert wird. Allerdings unterstützen WSDL-basierte Webdienst-Anbieterendpunkte nur wenige dieser Serialisierungsattribute. In wenigen Fällen sind die für den Webdienst-Endpunkt generierte WSDL-Datei und die resultierenden XML-Nachrichten nicht mit der ursprünglichen WSDL-Datei konsistent, aus der der Webdienst-Anbieterendpunkt erstellt wurde.

Tipp:

Wenn solche Probleme auftreten, können Sie das Dienstprogramm Wsdl.exe verwenden, um die Webdienstklasse und die Klassen für die Datenserialisierung zu generieren, anstatt einen Webdienst-Anbieterendpunkt aus einer WSDL-Datei zu erstellen. Anschließend müssen Sie den generierten Code jedoch manuell im Projekt einfügen und die erforderliche ASMX-Datei erstellen. Danach wird ein richtiger Webdienst-Anbieterendpunkt angezeigt. Sie können dann den Designer zum Bearbeiten des Endpunkts verwenden.

Die folgende Liste enthält weitere Informationen zur Unterstützung dieser Serialisierungsattribute:

  • Diese XML-Serialisierungsattribute werden Klassen hinzugefügt, die für komplexe XML-Typen generiert wurden: SerializableAttribute, SoapTypeAttribute, XmlIncludeAttribute, XmlRootAttribute und XmlTypeAttribute.

  • Diese XML-Serialisierungsattribute werden Klassenfeldern hinzugefügt: XmlAnyAttribute, XmlArrayAttribute, XmlArrayItemAttribute, XmlAttributeAttribute, XmlChoiceIdentifierAttribute, XmlElementAttribute, XmlEnumAttribute, XmlIgnoreAttribute, XmlNamespaceDeclarationsAttribute und XmlTextAttribute.

  • Auf den Rückgabetyp für Webmethoden werden keine Serialisierungsattribute angewendet.

  • Auf die Parameter von Webmethoden werden keine Serialisierungsattribute angewendet.

  • Die folgenden SOAP-codierten Serialisierungsattribute werden auf diese Klassen nicht angewendet: SoapElementAttribute, SoapIgnoreAttribute, SoapAttributeAttribute, SoapAttributeOverrides, SoapAttributes, SoapEnumAttribute und SoapIncludeAttribute.

  • Attributargumente, die einen komplexen XML-Typ erfordern, werden als Zeichenfolgentyp mit dem vollqualifizierten Namen des Typs generiert. Dies verursacht einen Compilerfehler, der korrigiert werden muss.

    So wird <XmlIncludeAttribute(GetType("ClassName"))> z. B. in Visual Basic als <XmlIncludeAttribute("ClassName")> generiert, wohingegen [XmlIncludeAttribute(typeof("ClassName"))] in Visual C# als [XmlIncludeAttribute("ClassName")] generiert wird.

Siehe auch

Aufgaben

Gewusst wie: Hinzufügen von Endpunkten zu Anwendungen

Gewusst wie: Anpassen von Webdienst-Endpunkten an WSDL-Dateien

Konzepte

Übersicht über Endpunkte in Anwendungen