Web Services mit .NET Framework 2.0 und Visual Studio 2005
Veröffentlicht: 17. Jun 2005
Von Jürgen Mauerer
Das .NET Framework 2.0 bietet viele interne Verbesserungen für die Entwickler von ASP.NET Web Services (ASMX). Es gibt ein neues und vereinfachtes Modell für den asynchronen Aufruf von Web Services sowie erweiterte Funktionen für die Verarbeitung und Erzeugung von XML. Auch der neue Standard SOAP 1.2 wird unterstützt. Dieses Feature stellt die Neuerungen in ASMX auf Basis der Beta 2-Version des .NET Framework 2.0 vor.
Auf dieser Seite
Web Services - eine Einführung
Interoperabilität, XML-Serialisierung und Proxy Code-Generierung
Asynchrone Methodenaufrufe und gemeinsame Nutzung von Typen
Netzwerk-Information und bessere Performance
Web Services - eine Einführung
Web Services sind das beste technologische Mittel zur Realisierung eines service-orientierten Ansatzes. Web Services-Anwendungen kommunizieren über offene Internetprotokolle, beschreiben Nachrichten mittels XML-Schemas und basieren auf drei Kern-Standards: SOAP (Simple Object Access Protocol), WSDL (Web Services Description Language) und XSD (XML Schema).
SOAP arbeitet mit einer XML-Syntax und beschreibt das interoperable Format, mit dem Nachrichten zwischen Web Services und deren Konsumenten ausgetauscht werden. Als Protokoll kann man unterschiedlichste Transportmedien verwenden. Heutzutage wird in erster Linie HTTP eingesetzt, allerdings gibt es auch Implementierungen, die TCP oder etwa MSMQ unterstützen.
WSDL ist ein XML-Derivat und beschreibt die Schnittstellendefinitionen eines Web-Service. Dieses Metadatenformat beschreibt das Format von Nachrichten und deren Korrelation. Es unterstützt verschiedene Nachrichtenaustauschmuster wie Einweg, Anfrage/Antwort oder Notifizierung.
XSD (XML Schema Definition) bestimmt die Regeln, denen ein XML-Dokument folgen muss. XML Schemas sind somit formale Spezifikationen aller in einem Dokumenttyp erlaubten Strukturen, also eine Art formale Grammatik. Stimmen die Tags in der XML-Datei nicht mit der XSD überein, kann bei aktivierter Validierung in XML Parsern ein Fehler gemeldet werden, ansonsten ist die XML-Datei korrekt. Die Beschreibung der XML-Datenstruktur mit Hilfe von Schemas vereinfacht den Datenaustausch, da Web Services und deren Konsumenten dadurch klar darüber informiert sind, wie die Daten auszusehen haben.
Web Services mit ASP.NET (ASMX) setzen auf ASP.NET auf; die so genannte ASMX-Engine ist in die ASP.NET-Laufzeitumgebung integriert und übernimmt beispielsweise die XML-Serialisierung der Objekte und andere wichtige Aufgaben. ASMX bietet Request/Response über HTTP für SOAP-Nachrichten, ist relativ einfach zu programmieren und bietet viele Möglichkeiten zur Manipulation der Nachrichten mittels Serialization-Attributen.
Einen Schritt weiter gehen Web Services mit WSE (Web Services Enhancements), einem Add-On von Microsoft für das .NET Framework. Web Services mit WSE machen echtes SOAP Messaging möglich, sind nicht an HTTP gebunden und bieten mehr als nur Request/Response. Sie realisieren WS-*-Spezifikationen wie WS-Security, WS-Trust, WS-SecureConversation oder WS-SecurityPolicy. Sie können ASMX um Messaging und Security (mit oder ohne Policy) erweitern und bieten umfangreiche Hosting-Möglichkeiten.
In seiner neuen Kommunikationsplattform mit dem Codenamen Indigo führt Microsoft die Features aller Kommunikationstechnologien der CLR (ASMX, WSE, .NET Remoting, System.Messaging und .NET Enterprise Services) in einer einheitlichen Laufzeitumgebung mit einem einheitlichen Programmiermodell zusammen. Indigo unterstützt die WS-*-Spezifikationen und setzt stark auf eine service-orientierte Entwicklung. XML und SOAP bieten unter Indigo zusätzliche Sicherheitsmerkmale, Transaktionsunterstützung und zuverlässige Nachrichtenübermittlung.
Gegenstand dieses Features sind aber ausschließlich die Verbesserungen, die das .NET Framework 2.0 für Web Services mit ASP.NET (ASMX) bringt.
Developer Center Web Services
Das Developer Center zu Web Services auf MSDN USA bietet die wichtigsten Informationen zum Thema in Form von Webcasts, technischen Artikeln, Blogs oder Newsgroups.
Developer Center Web Services
Web Services verknüpfen ursprünglich isolierte Anwendungen miteinander. Dahinter stehen Technologien wie .NET Remoting oder SOA (Service-Oriented Architecture). In diesem Developer Center von MSDN Deutschland finden Sie nähere Informationen zum Thema.
.NET Framework 2.0 - neue Features für Web Services-Entwickler
Das .NET Framework 2.0 bietet eine Menge Verbesserungen für die Entwickler von XML Web Services. So wurde die XML-Performance erheblich gesteigert, neue Standards wie W3C SOAP 1.2 werden unterstützt, die XML-Funktionen wurden erweitert und es gibt ein neues und vereinfachtes Modell für den asynchronen Aufruf von Web Services. In englischer Sprache. Der Artikel bezieht sich auf die Beta 1 des .NET Framework 2.0.
Interoperabilität, XML-Serialisierung und Proxy Code-Generierung
Interoperabilität
Web Services, die mit Visual Studio 2005 erzeugt werden, stimmen in der Grundeinstellung mit dem WS-I Basic Profile 1.1 überein. Das Basic Profile der Web Services Interoperability Organization (WS-I.org) wird von allen Web Services-Herstellern unterstützt und stellt eine Art Sammlung von Standards dar, die das plattformunabhängige Arbeiten ermöglichen und die Interoperabilität zwischen Web Services verbessern. Zu den Standards gehören UDDI, WSDL, SOAP, XML 1.0 und XSD.
Das .NET Framework 2.0 bietet für Web Services, die mit dem WS-I Basic Profile 1.1 übereinstimmen sollen, den Parameter ConformsTo im WebServiceBindingAttribute, der das Profil festlegt, dem der Web Service folgen soll. In der Beta 2 gibt es dafür in den WsiProfiles genau zwei Werte: None und BasicProfile1_1. Ein weiterer Weg, die Übereinstimmung mit dem Basic Profile 1.1 zu sichern, ist es, die Eigenschaft EmitConformanceClaims auf true zu setzen. Dann geht das WSDL des Web Services mit dem Basic Profile 1.1 konform. Beim Gebrauch eines Web Services überprüft beispielsweise das Hilfswerkzeug wsdl.exe WSDL-Dateien auf Übereinstimmung mit dem Basic Profile 1.1 und meldet, wenn diese nicht vorliegt.
Es gibt nämlich einige Funktionen oder Einstellungen, die nicht mit dem WS-I Basic Profile 1.1 übereinstimmen und eine Ausnahme bilden, wenn man den Web Service oder dessen WSDL aufruft. Dies ist beispielsweise beim SOAP-Encoding über die Attribute SoapRpcService oder SoapRpcMethod der Fall. Um diese nicht-konformen Funktionen zu nutzen, brauchen Sie nur die Eigenschaft WebServiceBindingAttribute.ConformanceClaims auszuschalten.
Standard SOAP 1.2
Web Services unterstützen im .NET Framework 2.0 jetzt das W3C SOAP 1.2-Protokoll in Ergänzung zu SOAP 1.1. Serverseitig ist SOAP 1.2 und 1.1 möglich, in der Grundeinstellung ist SOAP 1.2 aktiviert. Die Abschaltung erfolgt über Konfigurations-Einstellungen in machine.config oder web.config.
Unterstützt der Server sowohl SOAP 1.1 als auch SOAP 1.2, kann der Client eines der beiden Protokolle auswählen. Die Konfiguration erfolgt hier in der Proxy-Klasse über die SoapProtocolVersion-Eigenschaft, zum Beispiel proxy.SoapVersion = System.Web.Services.Protocols.SoapProtocolVersion.Soap12. In wsdl.exe wiederum gibt man für SOAP 1.2 folgenden Ausdruck in die Kommandozeile ein: /protocol: SOAP12.
XML-Serialisierung
Das .NET Framework 2.0 unterstützt die Funktion IXmlSerializable jetzt vollständig in den ASP.NET Web Services. IXmlSerializable gibt es zwar bereits seit dem .NET Framework 1.0, allerdings nicht dokumentiert und speziell auf System.Data.DataSet bezogen. IXmlSerializable unterstützt in .NET 2.0 unter anderem Null-fähige Typen(Nullable Types) und Generics. Um mit der bestehenden Schnittstelle kompatibel zu sein, blieben die Methoden und Signaturen unverändert, die Methode IXmlSerializable.GetSchema jedoch sollten Entwickler nicht mehr verwenden.
Neu im .NET Framework 2.0 ist das Attribut XmlSchemaProvider, das zusammen mit IXmlSerializable die statische Methode anzeigt, mit deren Hilfe das Schema erzeugt und in das interne XmlSchemaSet eingefügt wird. Über diese statische Methode erhält der Entwickler volle Kontrolle über die Schema-Erzeugung. Die XmlSchemaProviderAttribute-Klasse zeigt den Namen der Methode an, mit deren Hilfe das Schema dem internen Schema-Set hinzugefügt wird. Sie nimmt ein XmlSchemaSet und gibt den XmlQualifiedName des Start-Elements zurück.
Für die XML-Serialisierung sind zwei grundlegende Methoden zu implementieren: WriteXml und ReadXml. WriteXml verwandelt ein Objekt in seine XML-Repräsentation. Die ReadXml-Methode erzeugt ein Objekt aus seiner XML-Repräsentation und nutzt dabei die Informationen, die vorher von der WriteXml-Methode bereitgestellt wurden. Die ReadXml-Methode beginnt beim Start-Tag des serialisierten Objektes, also auch dort, wo die WriteXml-Methode beginnt.
IXmlSerializable hilft auch beim Streaming von großen Datenmengen. Dazu müssen Sie das Response-Buffering ausschalten und die Daten in kleinere Datenblöcke aufteilen, die durch XML-Elemente getrennt sind. Über IXmlSerializable lässt sich das Schema dieses Formats sowie mit der ReadXml- und der WriteXml-Methode das Lesen und Schreiben der Daten im Datenstrom kontrollieren.
Proxy Code-Generierung
Nutzt man Add Web Reference oder wsdl.exe, interpretiert die Web Services-Infrastruktur das WSDL des Ziel-Services und generiert Proxy-Klassen, um mit diesem Service zu interagieren. Das .NET Framework 2.0 führt verschiedene neue Funktionen ein, um die generierten Proxy-Klassen benutzerfreundlicher zu machen. Neu ist die SchemaImporterExtension für das einfache Erzeugen von Proxy-Code.
Die neue Basisklassen SchemaImporterExtension ermöglicht die einfache Code-Generierung beim Import von Schemas. Die Extensions erben von der Basisklasse, implementieren die Schema-Eigenschaften (z.B. Namensraum, Element) und fügen den Code hinzu. Extensions sind Typen, die sich über Code oder über Konfigurationseinträge hinzufügen und registrieren lassen und beim Import des Schemas aufgerufen werden, um Proxy-Code für das Schema und WSDL zu erzeugen.
Während des Schema-Imports wird jede Extension in der konfigurierten Reihenfolge für den entsprechenden Schema-Typ aufgerufen und kann entscheiden, ob sie den Code einfließen lässt oder den Schema-Typ ignoriert.
Webcast Web Services mit Visual Studio 2005, Teil 1
Webcast Teil 2
Web Services und .NET sind seit Jahren nicht voneinander zu trennen. Mit dem .NET Framework 2.0 hat Microsoft seine Hausaufgaben gemacht und die ASMX-basierten Web Services poliert. Zwar gibt es keine großartigen Neuerungen im Umfeld aktueller, weiter führender Standards - jedoch sind viele kleine interne Verbesserungen vorgenommen worden, um die alltäglichen Unwägbarkeiten von Web Services etwas zu lindern. Dieses Webcast-Doppelpack zeigt, welche neuen Funktionen das sind.
Asynchrone Methodenaufrufe und gemeinsame Nutzung von Typen
Asynchrone Methoden-Aufrufe
Das neue ereignisbasierte asynchrone Programmiermodell des .NET Framework 2.0 vereinfacht auch den asynchronen Aufruf von Web Services. Es verwendet ein Event-basiertes Muster statt des klassischen BeginInvoke/EndInvoke-Paares und sorgt für die automatische Thread-Synchronisation, so dass der Ereignis-Handler auf demselben Thread abläuft, der den asynchronen Aufruf gestartet hat. Die so genannte RAD Async-Funktion erlaubt Entwicklern, ein ereignisbasiertes Modell für den asynchronen Aufruf von Web Services zu verwenden.
Zunächst ist hier die Klasse [OperationName]CompletedEventArgs, die von der Klasse System.ComponentModel.AsyncCompletedEventArgs erbt. Diese neue Klasse gibt das Resultat des asynchronen Aufrufs über die Result-Eigenschaft aus, deren Typ dem Typen des zurückgegebenen Werts der synchronen Methode entspricht. Nutzen Sie in Ihrem Web Service eine Methode namens GetData, die ein DataSet zurückgibt, erhalten Sie eine korrespondierende Proxy-Klasse namens GetDataCompletedEventArgs mit einer Result-Eigenschaft vom Typ System.Data.DataSet.
Als zweites wird der Delegate [OperationName]CompletedEventHandler erzeugt, die von der Klasse System.ComponentModel.AsyncCompletedEventHandler erbt. Dieser Delegate besitzt zwei Parameter, den Sender und eine Instanz von [OperationName]CompletedEventArgs. Als nächstes wird mit dem Delegate-Typen [OperationName]CompletedEventHandler ein Ereignis der Proxy-Klasse selbst namens [OperationName]Completed erzeugt.
Zum Schluss wird schließlich die asynchrone Methode selbst generiert. Es gibt dabei zwei Überladungen der Methode. Eine der Überladungen akzeptiert auch den Parameter asyncState vom Typ Object. Dieser Parameter wird als Cookie genutzt, um die asynchrone Methode mehrfach im selben Client aufzurufen und diese Aufrufe dann zu unterscheiden, wenn das Ereignis [OperationName]Completed gestartet wird.
Gemeinsame Nutzung von Typen
In der Praxis kommt es häufig vor, dass verschiedene Web Services einen oder mehrere Datentypen gemeinsam nutzen. Dies ist beispielsweise der Fall bei einem Bestelleingangs-Service, der das bestellte Objekt weiterleitet, und einem Bestellstatus-Service, der ein bestelltes Objekt aufnimmt. Wenn ein Client beide Services nutzen will, erzeugt die heutige Version bei der Codegenerierung zwei Bestellklassen in unterschiedlichen Namensräumen.
Mit dem .NET Framework 2.0 wird das alles einfacher. Es bietet dem Client nur noch eine einzige Bestellklasse, die von zwei Service-Proxies geteilt wird. Das Tool wsdl.exe stellt diese Funktion mit dem /sharetypes-Switch bereit. Dieser Switch nimmt die URLs von zwei oder mehr WSDL-Dokumenten in der Kommandozeile entgegen. Die Code-Engine erkennt anhand des Namens, des Namensraumes und der Schema-Definition die übereinstimmenden Typen und generiert dann einen einzigen CLR-Typen.
Weblog Christian Weyer
Christian Weyer führt auf seinem Weblog in einer mehrteiligen Serie in die Neuheiten von Web Services mit dem .NET Framework 2.0 ein. In englischer Sprache. Christian Weyer ist Mitgründer von thinktecture und unabhängiger Microsoft Regional Director in Deutschland sowie Microsoft MVP Solution Architect. Seine Spezialgebiete sind Verteilte Anwendungen, Web Services und Interoperabilität mit der Java-Welt.
Netzwerk-Information und bessere Performance
Netzwerk-Information
Klassen im Namensraum NetworkInformation ermöglichen Anwendungen, automatisch Proxy-Server bzw. das bestehende Netzwerk und deren Eigenschaften zur Laufzeit zu erkennen. Sie benachrichtigt die Anwendung bzw. den Benutzer, wenn sich die Netzwerkumgebung verändert, beispielsweise bei Änderungen der Adresse, bei Unterbrechung der Netzwerkverbindung etc. Zudem bietet das .NET Framework 2.0 ein API zur Auflistung der Zugangsarten (z.B. Ethernet, Dial-Up, Wireless) sowie statistische Werte zu IP, TCP oder UDP (z.B. geöffnete Verbindungen, Ports etc.).
Bessere Performance
Frühzeitige Erstellung der Serialisierungs-Assemblies
Der XmlSerializer erzeugte bislang den Code und die Assemblies für die Serialisierung beim ersten Zugriff auf die zu serialisierenden Typen beispielsweise beim ersten Aufruf eines Web Services (on the fly). Bei komplexen Proxies mit zahlreichen Typen kann die Erstellung des Serialisierungs-Codes länger dauern und dadurch den Start des Web Services verzögern.Um dies zu verhindern, gibt es mit dem .NET Framework 2.0 ein neues Werkzeug namens sgen.exe, das die Serialisierungs-Assemblies schon zur Entwurfszeit generiert. Die frühzeitig erstellte Assembly wird dann zur Laufzeit geladen und vermeidet dadurch Verzögerungen beim Start des Web Services. Sgen.exe durchläuft alle Typen in einer Assembly und erzeugt den notwendigen Serialisierungs-Code, der dann zur Laufzeit gemeinsam mit den Assemblies der Anwendung geladen wird. Die Zeit für die Instanziierung des Proxys reduziert sich dadurch erheblich.
Dekomprimierung von HTTP-Antworten
Microsoft IIS 6.0 komprimiert unter Windows Server 2003 HTTP-Antworten und damit auch Antwortnachrichten von Web Services. Dies führt zu einer besseren Ausnutzung der Bandbreite. Das .NET Framework 2.0 wiederum unterstützt die Dekomprimierung der HTTP-Antworten.
Weblog Yasser Shohoud
Yasser Shohoud ist Program Manager bei Microsoft. In seinem englischsprachigen Weblog befasst er sich unter anderem mit den neuen Funktionen der ASP.NET Web Services im .NET Framework 2.0.