Comelio GmbH MS SQL Server: Grundlagen SOAP Webservices - MS SQL Server T-SQL XML Webservices Programmierung Bücher Anleitung Tutorial Skulschus Wiederstein Kozik XML Reporting .NET Webservices Server T-SQL Intelligence SQL Analysis Services Microsoft Bücher Business MS Lübeck Kassel Leipzig Erlangen Magdeburg Koblenz München Freiburg Frankfurt Heidelberg Wolfsburg Bremen Ludwigshafen Köln Zwickau Koblenz Hamburg Mannheim Göttingen Berlin Stuttgart Hannover Andernach Aachen Bochum Bonn Ol Kiel Würzuburg Rügen Ingolstadt

Das Visual Studio erstellt selbstständig eine so genannte Proxyklasse, mit welcher der Webservice genutzt werden kann. Als Ergebnis erhält man nach dem Operationsaufruf bspw. ein Objektarray oder ein DataSet zurück. Nichtsdestoweniger ist es durchaus möglich, die XML-Datei zu erstellen, zu versenden und die zurückerhaltene Datei auch wieder auszulesen, d.h. den gesamten Vorgang auf XML-Ebene direkt durchzuführen. Insbesondere beim Einrichten und Testen eines Dienstes ist es hilfreich, eine Möglichkeit zu haben, den eingerichteten Webservice direkt über XML zu verwenden und damit auch unmittelbar seine Funktionen zu testen. Der folgene Abschnitt stellt daher die Formate von drei verschiedenen Nachrichten vor, die im Rahmen solcher Tests auftreten, wobei hier wie bei den Beispielen zur Erstellung von Klienten der Fokus weniger auf allgemeinen Webservices, sondern auf derVerwendung von MS SQL Server-Webservices liegt. Diese bieten eine Reihe von eigenen Elementen, die zum Verständnis der Dateien notwendig sind.

Namensräume

Bei den verschiedenen Dateien kommen die folgenden Namensräume zum Einsatz. Sie werden in den Beispielen, welche die möglichen SOAP-Dateien von eingerichteten Webservices als Illustration zeigen, gestrichen, um die Dateien, die ohnehin schon für den Abdruck fast zu lang sind, weiter zu kürzen. Die Tilde (~) ersetzt die Zeichenkette http://schemas.microsoft.com/sqlserver/2004.

Allgemeiner Aufbau

Das SOAP-Format ist aus XML-Sicht nicht besonders umfangreich, da es im Wesentlichen als Container für die zum Server übermittelte Nachricht in XML-Format dient. Je komplexer diese Nachricht ist, desto geringeren Anteil am XML-Baum haben die eigentlichen SOAP-Elemente. Während jeder Webservice eine eigene XML-Nachricht erwartet, dient SOAP dazu, der gesamten Nachricht einen Rahmen zu geben, der automatisiert ausgelesen werden kann und der es ermöglicht, die eigentliche Nachricht von zusätzlichen Informationsbestandteilen zu trennen.

SOAP wird aufgrund seiner Elementbezeichnungen immer als Brief dargestellt, da seine wesentlichen Elemente Header und Body in einem Envelope-Element platziert werden und tatsächlich Kopfdaten und den eigentlichen Inhalt enthalten. Zum Server wird allerdings nicht nur eine XML-Nachricht geschickt, sondern tatsächlich eine gesamte HTTP-Anfrage, normalerweise per POST. Eine solche Gesamtanfrage besteht bspw. aus den nachfolgenden Zeilen, wobei diese unbedingt not-wendig sind und das Protokoll, die HTTP-Version, den Host, die Anfrageart, die Gesamtlänge der Nachricht und die aufgerufene Methode bezeichnen. Danach erst beginnt der XML-Teil der Nachricht. Sofern man also tatsächlich selbst eine solche Nachricht versenden will, muss in der Anfrage auch dieser Beginn enthalten sein.

Als Material für die Darstellung und Spezifikation von SOAP stellt das W3C im Wesentlichen folgende Dokumente bereit: Einführung (SOAP Version 1.2 Part 0: Primer , http://www.w3.org/TR/2003/REC-soap12-part0-20030624/), Nachrichten-struktur (SOAP Version 1.2 Part 1: Messaging Framework, http://www.w3.org/TR/2003/REC-soap12-part1-20030624/), Kopfdaten (Resource Representation SOAP Header Block, http://www.w3.org/TR/2005/REC-soap12-rep-20050125/). Ein XML Schema für die SOAP-Nachricht ist unter http://www.w3.org/2003/05/soap-envelope/ verfügbar.

In der Datei SoapSchema.xsd finden Sie das XML Schema, das zu SOAP bereitgestellt wurde. Man erkennt in einer entsprechenden grafischen Darstellung, dass das Header-Element optional ist und sowohl Header wie Body beliebige Elemente und Attribute anderer Namensräume enthalten können.

Batch-Anweisungen

Es besteht die Möglichkeit, einen Webservice auch dann zu verwenden, wenn gar keine Prozedur oder Funktion angegeben wurde, die ihn ausfüllt. In diesem Fall kann man Ad-hoc-SQL-Abfrageausführungen freischalten, was dazu führt, dass man direkt T-SQL-Anweisungen, die durch ein Semikolon getrennt werden, verschickt. Dazu existiert eine eigene Nachrichtenstruktur, die nicht zu SOAP, sondern zum MS SQL Server gehört. Dabei ruft man die Methode sqlbatch() auf. Die T-SQL-Anweisungen befinden sich im Kind BatchCommands, wobei die einzelnen Anweisungen mit einem Semikolon getrennt sind und Binde-Parameter erwarten. Diese werden innerhalb eines Geschwister-Elements als Parameter in einzelnen SqlParameter-Elementen deklariert. Dazu stehen für die Beschreibung der Datentypen eine umfangreiche Liste an Attributen bereit. Wenigstens muss man den Namen im Name-Attribut und den Wert im Value-Attribut angeben. Der Wert wird als Element übergeben, weil auch XML-Parameter möglich sind, die in einem Attribut nicht gespeichert werden könnten. Je genauer die Angabe des Datentyps erfolgt, desto weniger Hürden bei der Umwandlung gibt es.

WSDL

Die WSDL (Web Service Description Language) ist ebenfalls ein XML-Format, das für die Verwendung eines SOAP-Webdienstes zum Einsatz kommt. Hierbei gibt es zwei Möglichkeiten: entweder man akzeptiert und verwendet die WSDL-Datei, die vom MS SQL Server automatisch bereit gestellt wird, oder man erstellt eine eigene und meldet diese beim Server an. Die XML-Datei beschreibt in beiden Fällen den gesamten Webservice mit seinen Methoden, seinen Adressen, den Nachrichtenstrukturen und Datentypen. Das Format vom MS SQL Server ist besonders umfangreich gehalten, wenn man die erweiterte Fassung verwendet, die nur von der Datenbank verstanden wird. Es lässt sich allerdings auch ein einfaches WSDL-Format verwenden, welches weniger MS SQL Server-spezifische Elemente aufweist. Sie unterscheiden sich im Hinblick auf die Nachrichten im Wesentlichen in der Form, wie XML Schema zum Einsatz kommt. Mit XML Schema lassen sich die Anfrage-/ Antwort-Strukturen beschreiben, was daraus hinausläuft, dass sowohl die einfachen Datentypen von Eingabe- und Ausgabeparametern als auch komplexe Nachrichten in XML Schema beschrieben werden. Hier verwendet das erweiterte Format ebenfalls erweiterte Techniken aus XML Schema, um die Strukturen der Nachrichten zu verwenden.

Um das Standard- oder erweiterte WSDL abzurufen, genügt es, die URL http://server/endpoint_path?wsdl aufzurufen. Die Funktionalität, an den URI des Webservice den Spezial-Parameter ?wsdl anzuhängen, ist bei jedem Webservice vorhanden und wird vom Applikations-/Webserver automatisch angeboten. Die einfache WSDL-Form lässt sich über die URL http://server/
endpoint_path?wsdlsimple abrufen. Das benutzerdefinierte WSDL ruft man über die Standard-Form auf, wobei allerdings eine zuvor vom Webservice-Anbieter angegebene eigene WSDL-Datei zurückgegeben wird, die den Webservice beschreibt.
Die nächsten beiden Abschnitte beschreiben Standard-WSDL und das vereinfachte WSDL mit Blick auf die Besonderheiten vom MS SQL Server. Danach folgt eine Übersicht über die WSDL-Syntax an sich, die grundsätzlich unabhängig von der Nutzung und Umsetzung im MS SQL Server ist. In der sehr umfassenden XML Schema-Insel, die sich im Dokument befindet, sind neben der Antwort und Anfrage auch die XML-Elemente enthalten, die speziell für den MS SQL Server für Sitzungs-, Transaktionsverwaltung und SQL-Batch-Anweisungen genutzt werden.

Standard-WSDL

Das Standard-WSDL liefert der MS SQL Server automatisch zurück, wenn die Zeichenfolge ?wsdl an die URL des Dienstes angehängt wird und kein benutzerdefiniertes WSDL angegeben wurde. Die Elemente, welche die Parameter enthalten, die an den Webdienst übergeben werden, werden mit sqltypes:type-Zuordnungen (nachfolgende Tabelle) zugeordnet und beschrieben. Ihnen stehen Entsprechungen auf .NET-Seite zur Verfügung. Zusätzlich können weitere Einschränkungen über XML Schema-Fassetten und in jedem Fall bei Zeichenfolgen und binären Datentypen die XML Schema-Fassette maxLength für die maximale Länge der möglichen Zeichenkette angegeben werden. Sofern die Zeichenfolgen mit (max) in der Prozedur/Funktion angegeben wurden, entfällt diese Fassette dagegen. Die Zahldatentypen decimal und numeric in XML Schema verwenden die beiden Fassetten totalDigits (Anzahl Stellen) und fractionDigits (Anzahl Dezimalstellen).

Die WSDL-Datentypen stammen aus dem zuvor angegebenen Namensraum http://schemas.microsoft.com/sqlserver/2004/sqltypes mit dem Standard-Präfix sqltypes. Er wurde hier aus Platzgründen ausgelassen. In einem .NET-Client befinden sich die zugehörigen und kompatiblen Datentypen im Namensraum System.Data.SqlTypes. Aus Platzgründen wurde er durch ein Tildenzeichen (~) ersetzt. Der Datentyp xml wird einem Klassenwrapper für ein Array von System.Xml.XmlNode-Objekten zugeordnet. Sofern es sich um nicht typisiertes XML handelt, lautet diese Wrapperklasse xml, ansonsten hat sie einen automatisch generierten Namen. Der Datentyp System.Xml.XmlElement wird einer Wrapperklasse um ein einzelnes System.Xml.XmlElement-Objekt zugeordnet. Der Name wird automatisch erstellt.

Für die Illustration einer einfachen Nachricht, die in der Standard-WSDL-Datei beschrieben wird, kann man die Datei 4231_01.wsdl betrachten. Sie wird später noch einmal genauer untersucht, kann allerdings ohnehin aus Platzgründen nicht vollständig abgedruckt werden. Die beschriebenen Datentypen werden in XML Schema-Form einzeln beschrieben, d.h. mit Hilfe der XML Schema-Syntax für den Klienten aufgeführt, was die Dateien natürlich sehr verlängert. Nachfolgend ist bspw. der Datentyp smallmoney mit Hilfe von XML Schema ausgedrückt und als Ableitung von xs:decimal angegeben. Dieser legt fest, dass es sich um eine Dezimalzahl handelt, deren Ober- und Untergrenze sowie (Dezimal-)Stellenanzahl auf Basis des Standarddatentyps weiter eingeschränkt wird. Andere Datentypen, wie man mit einem Blick in das angegebene Dokument feststellt, werden dagegen intensiv über reguläre Ausdrücke beschrieben.

Einfaches WSDL

Das vereinfachte WSDL erhält man, in dem man an die URL des Webservice den Parameter ?wsdlsimple anhängt. Dieser verwendet einige Vereinfachungen hinsichtlich der Datentypen. Die Systemdatentypen der Datenbank werden hier durch primitive XML Schema-Datentypen umgesetzt, sodass die zusätzlichen Einschränkungen, wie sie zuvor auch exemplarisch dargestellt wurden, entfallen. Dies führt verständlicherweise auf der einen Seite zu einer geringeren Komplexität an Datentypunterscheidungen und Validierungsmöglichkeiten, vereinfacht aber auf der anderen Seite auch die Verwendung durch Klienten, die möglicherweise mit den detailreichen Informationen nicht umzugehen wissen. Genau in dieser Vereinfachung und Abwärtskompatibilität ist der Vorteil des vereinfachten WSDL zu sehen.

So würde also bspw. aus der oben erwähnten Typableitung für Währungseinheiten ohne Dezimalstellen einfach nur die Zuweisung zu einer Ganzzahl erfolgen.

Allgemeiner Aufbau

Die verschiedenen Datentypen und die Nachrichtenstrukturen für Antwort und Anfrage stellen nicht die einzigen Inhalte der WSDL-Datei dar. Dieser Abschnitt beschreibt die wesentlichen Bereiche in einer solchen Datei, die sich um die XML Schema-Inseln sowie weitere Erweiterungselemente ranken. In dieser Hinsicht ähnelt das Grundprinzip von WSDL dem von SOAP, wobei bei der Webservice-Beschreibung deutlich mehr Elemente bereits vorgegeben sind.

Die unterschiedlichen, kurz von ihrer Bedeutung her zusammengefassten Bereiche sollen nun noch einmal detaillierter erfasst werden. Die verschiedenen Webservices, die später in diesem Kapitel zur Illustration erstellt werden, bieten dann jeweils auch die beiden automatisch generierten WSDL-Dateien oder eine individuell erstellte Datei. Hier ist es insbesondere wichtig, die grobe Struktur zu erfassen, die wiederholten Elemente, die in jeder Datei enthalten sind (Datentypdefinitionen, Aufzählungen), zu erkennen und dann aus den vielen hundert Zeilen Quelltext die tatsächlich informativen zu filtern. Im Rahmen der Verwendung von Webservices im Visual Studio kann hierbei auf diese Arbeit oftmals verzichtet werden, weil die Entwicklungsumgebung den Programmierer unterstützt, den Dienst aufzurufen und zu verwenden.

Innerhalb der nachfolgenden Syntax, die – durchgehend gelesen – ein allgemeines WSDL-Dokument ergibt, sind die Häufigkeiten wie in der DTD über Symbole angegeben, die natürlich im eigentlichen XML-Dokument keine Bedeutung haben und auch als Textknoten dort nicht erscheinen dürfen. Ein Fragezeichen steht für einen optionalen Knoten, ein Sternchen für einen wiederholt auftretenden Knoten. An verschiedenen Stellen tritt in einem XML-Kommentar der Hinweis auf Erweiterungselemente auf, die den Sprachumfang erweitern. Sie müssen allerdings vom WSDL-Interpreter verstanden werden.

Das Wurzelelement lautet definitions. Es erlaubt, in Attributen einen Namen für das Dokument sowie einen Zielnamensraum als URI zu vergeben.

Um Importe anzugeben, kann man mehrere import-Elemente verwenden, die zu einem Namensraum ein Dokument wie XML Schema oder WSDL angeben. Dies bedeutet, dass man WSDL-Dokumente modular aufbauen kann, um sie aus mehreren Teilen zusammenzusetzen oder wenigstens die XML Schema-Definitionen zu übernehmen.

Für Dokumentationszwecke kommt das documentation-Element mit beliebigem Inhalt für menschenlesbare Informationen zum Einsatz, das in jedem anderen Element innerhalb von WSDL auftreten kann.

Die Datentypen gibt man innerhalb des types-Elements an. Typischerweise verwendet man an dieser Stelle die Syntax und damit auch die Technik von XML Schema, wobei grundsätzlich auch andere Schema-Sprachen zum Einsatz kommen könnten. Da allerdings der MS SQL Server insbesondere XML Schema für die Validierung verwendet und dies für Datenbanken auch die beste Technik der XML-Modellierung darstellt, soll nur dies hier berücksichtigt werden.

Ein Porttyp bildet mit dem portType-Element eine Menge von abstrakten Operationen ab, die über abstrakte Nachrichten ausgeführt werden. Das name-Attribut bietet dabei eine Bezeichnerdefinition für diese Operation an. Unabhängig von den documentation-Elementen, die in jedem Kind-Element und in portType selbst auftreten können, gibt es drei mögliche abstrakte Nachrichtenelemente. Sie enthalten jeweils ein name-Attribut zur Bezeichnerdefinition. Das input-Element beschreibt eine eingehende Nachricht, die vom Klienten versendet und vom Server empfangen wird. Ein output-Element enthält eine ausgehende Nachricht, d.h. die Server-Nachricht, die vom Klienten verarbeitet wird. Eine Fehler-Nachricht ist in einem fault-Element enthalten.

Es wird in diesem Abschnitt grundsätzlich davon ausgegangen, dass die Nachrichten, die an einen Endpunkt verschickt werden, tatsächliche XML-Nachrichten sind. Dies bedeutet, dass eine komplexe XML-Struktur als Frage und/oder Antwort zum Einsatz kommt, die in Form einer XML Schema-Darstellung modelliert wird. Tatsächlich gibt es allerdings auch die Möglichkeit, so genannte RPC-Nachrichten (remote procedure call) zu versenden. Dies sind Webservices, die sich wie eine Funktion aufrufen lassen und keiner XML-Verarbeitung bedürfen. Je nach Programmiersprache kann dies eine viel einfachere Webservice-Verwendung bedeuten. Dies entspricht dann tatsächlich viel eher einem entfernten Prozeduraufruf.

Solche Operationen können leider in WSDL nicht direkt als solche erkannt werden. Man kann allerdings das Attribut parameterOrder einsetzen, indem eine XML-Liste die - wie der Name schon vermuten lässt - Parameterreihenfolge angibt, mit welcher die Operation aufzurufen ist. Es handelt sich dabei um die Namen von part-Elementen. Dies ist dann auch die Reihenfolge in der Funktions-/Prozedursignatur. Der Rückgabewert ist nicht in dieser Liste enthalten. Sofern ein Teil in input und output erscheint, handelt es sich um einen in/out-Parameter. Tritt er nur in der input-Nachricht auf, ist es ein in-Parameter, wohingegen es sich um einen out-Paramteer handelt, wenn er nur im output-Element erscheint. Diese ganzen Angaben fungieren als Hinweis und können auch übergangen werden.

Hinweis: Eine solche RPC-Variante eines Webservice stellt das erste Beispiel dar. Hier liefert die Eingabe einer Produktnummer eine XML-Datei zurück, in der Produktdaten enthalten sind.

WSDL kennt die folgenden vier primitiven Übertragungsarten, die ein Endpunkt anbietet. Sie werden von WSDL als Operationen wahrgenommen, da sie in ihrer Grundstruktur die verschiedenen Webservice-Modelle aus Sicht der Nachrichten abbilden.

Die primitiven Operationen erkennt man nicht an einem bestimmten Attribut oder Eltern-Element, sondern ausschließlich an ihrem Inhalt, der in XML-Form im nachfolgenden Quelltext angegeben ist.

SOAP-Erweiterungen

WSDL bietet über die Erweiterungselemente die Möglichkeit, weitere Elemente zu integrieren. Wie oben schon erwähnt, ist dies insbesondere für die so genannte SOAP-Bindung relevant, da hier spezielle Elemente bereit stehen, um SOAP-Endpunkte zu referenzien und zu beschreiben. Diese Elemente enthalten die Angaben, dass eine Bindung überhaupt dem SOAP-Protokoll entspricht, wie die Adresse (URI für SOAPAction für die HTTP-Übertragung) des SOAP-Endpunktes lautet und welche Header-Informationen übertragen werden können.

Dieser Abschnitt erklärt die verschiedenen zusätzlichen Elemente, die für SOAP-Webservices, wie sie vom MS SQL Server bereitgestellt werden, auch verfügbar sind. In der Datei SoapWSDL.xsd befindet sich das zugehörige XML Schema.

Das verpflichtende binding-Element gibt an, dass die in WSDL definierte Bindung dem SOAP-Protokollformat entspricht und daher Envelope, Header und Body als Nachrichtenelemente enthält. Im style-Attribut ist angegeben, ob eine XML-Nachricht (document, Standardwert) oder eine RPC-Nachricht (rpc) verschickt wird. Microsoft setzt für document das Wort literal ein. Das transport-Attribut enthält die Transporttechnik wie HTTP, SMTP oder FTP. Im Fall von HTTP-Übertragung ist dies der Wert http://schemas.xmlsoap.org/soap/http.

Im style-Attribut befindet sich die Angabe, ob die Operation eine RPC-Nachricht (Wert: rpc) oder dokumententorientiert (Wert: document oder literal, Standardwert) ist. Wie schon zuvor bedeutet hier eine RPC-Nachricht, dass die Nachricht in XML Parameter an eine Funktion/Prozedur übermittelt wird und auf Rückgabewerte wartet, während eine dokumentenorientierte Nachricht eine komplexe XML-Nachricht übergibt.

Das Attribut soapAction enthält den SOAPAction-Kopf-Eintrag als URI, den diese Operation benötigt, und ist daher für HTTP-Übertragung auch verpflichtend und als absoluter Pfad anzugeben.

Das body-Element legt die Nachrichtenteile des Body-Elements im SOAP-Dokument fest. Die Referenzierung erfolgt dabei über eine Liste von Bezeichnern, die sich zu Elementen oder globalen komplexen Typen auflösen können, wobei sich dies grundsätzlich für beide Nachrichtenarten verwenden lässt. Wenn das style-Attribut von operation den Wert rpc enthält, dann stellt jeder Teil einen eigenen (Rückgabe-)Parameter dar, welcher innerhalb eines umhüllenden Elements mit Namen der Operation im Body-Element von SOAP auftritt. Die Reihenfolge dieser Parameter entspricht der konkreten Reihenfolge in der Signatur von Funktion/Prozedur. Wenn das style-Attribut von operation dagegen den Wert document/literal enthält, dann ist ein solches umhüllendes Element unwichtig, was zur Folge hat, dass die Nachrichtenteile direkt innerhalb vom Body-Element in SOAP auftreten.

Das optionale parts-Attribut enthält eine XML-Liste mit den Namen der in der Nachricht auftretenden Teile. Wenn das Attribut fehlt, sind alle verfügbaren Teile in der Nachricht angekündigt.

Das verpflichtende use-Attribut gibt an, ob und mit welcher Technik die Teile kodiert sind. Wenn der Wert encoded ist, dann enthält jeder Nachrichtenteil eine Typangabe im type-Attribut. Sofern der Wert literal ist, ist jeder Teil mit einer XML Schema-Definition durch Elementverweis oder Typaufruf verknüpft.

Das optionale Attribut encodingStyle enthält in Form einer XML-Liste mit URIs die Kodierungsart wie in SOAP.

Das fault-Element enthält den Inhalt der Fehlernachricht. Die Attribute use, encodingStyle und namespace verhalten sich genauso wie im body-Element. Das name-Element hingegen bezieht sich auf das fault-Element aus WSDL.

Das Element header enthält die übermittelten Header-Informationen, während headerfault sich auf die Fehlermeldung aus dem Kopfbereich bezieht. Beide Elemente sind analog zu ihren Entsprechungen im body-Element modelliert. Innerhalb dieser beiden SOAP-Elemente können also verschiedene Nachrichtenteile wieder referenziert werden, die im Normalfall als XML-Dokument Nachrichten empfangen und versenden. Wenn man keine Header-Informationen verwendet, ist dies - wie schon erwähnt - durchaus nicht tragisch oder eine Schwäche der Datenmodellierung/Anwendung.

Das letzte mögliche Element ist address, welches einem Port eine URI-Adresse zuweist. Dabei ist einem SOAP-Port genau eine Adresse zuzuweisen.

Allgemeine Syntax

Dieser Abschnitt soll die allgemeine Syntax, welche für die Erstellung von SOAP-Webservices notwendig ist, kurz vorstellen. Die einzelnen Optionen werden dann unter verschiedenen Gesichtspunkten vorgestellt, da sie teilweise zu ganz anderen Webservices und Besonderheiten führen. Die Grundsyntax lautet schlichtweg CREATE ENDPOINT. Das Wort Webservice taucht hier nicht auf, weil man Webservices überhaupt auch als Endpunkte bezeichnen kann, und weil der MS SQL Server neben den hier diskutierten SOAP-Webservices noch weitere Techniken anbietet. Unmittelbar nach der Namensvergabe lässt sich dann mit STATE angeben, ob der Dienst auch sofort gestartet werden soll oder nicht.

Comelio GmbH MS SQL Server: Grundlagen SOAP Webservices - MS SQL Server T-SQL XML Webservices Programmierung Bücher Anleitung Tutorial Skulschus Wiederstein Kozik XML Reporting .NET Webservices Server T-SQL Intelligence SQL Analysis Services Microsoft Bücher Business MS Lübeck Kassel Leipzig Erlangen Magdeburg Koblenz München Freiburg Frankfurt Heidelberg Wolfsburg Bremen Ludwigshafen Köln Zwickau Koblenz Hamburg Mannheim Göttingen Berlin Stuttgart Hannover Andernach Aachen Bochum Bonn Ol Kiel Würzuburg Rügen IngolstadtComelio GmbH MS SQL Server: Grundlagen SOAP Webservices - MS SQL Server T-SQL XML Webservices Programmierung Bücher Anleitung Tutorial Skulschus Wiederstein Kozik XML Reporting .NET Webservices Server T-SQL Intelligence SQL Analysis Services Microsoft Bücher Business MS Lübeck Kassel Leipzig Erlangen Magdeburg Koblenz München Freiburg Frankfurt Heidelberg Wolfsburg Bremen Ludwigshafen Köln Zwickau Koblenz Hamburg Mannheim Göttingen Berlin Stuttgart Hannover Andernach Aachen Bochum Bonn Ol Kiel Würzuburg Rügen IngolstadtComelio GmbH MS SQL Server: Grundlagen SOAP Webservices - MS SQL Server T-SQL XML Webservices Programmierung Bücher Anleitung Tutorial Skulschus Wiederstein Kozik XML Reporting .NET Webservices Server T-SQL Intelligence SQL Analysis Services Microsoft Bücher Business MS Lübeck Kassel Leipzig Erlangen Magdeburg Koblenz München Freiburg Frankfurt Heidelberg Wolfsburg Bremen Ludwigshafen Köln Zwickau Koblenz Hamburg Mannheim Göttingen Berlin Stuttgart Hannover Andernach Aachen Bochum Bonn Ol Kiel Würzuburg Rügen IngolstadtComelio GmbH MS SQL Server: Grundlagen SOAP Webservices - MS SQL Server T-SQL XML Webservices Programmierung Bücher Anleitung Tutorial Skulschus Wiederstein Kozik XML Reporting .NET Webservices Server T-SQL Intelligence SQL Analysis Services Microsoft Bücher Business MS Lübeck Kassel Leipzig Erlangen Magdeburg Koblenz München Freiburg Frankfurt Heidelberg Wolfsburg Bremen Ludwigshafen Köln Zwickau Koblenz Hamburg Mannheim Göttingen Berlin Stuttgart Hannover Andernach Aachen Bochum Bonn Ol Kiel Würzuburg Rügen IngolstadtComelio GmbH MS SQL Server: Grundlagen SOAP Webservices - MS SQL Server T-SQL XML Webservices Programmierung Bücher Anleitung Tutorial Skulschus Wiederstein Kozik XML Reporting .NET Webservices Server T-SQL Intelligence SQL Analysis Services Microsoft Bücher Business MS Lübeck Kassel Leipzig Erlangen Magdeburg Koblenz München Freiburg Frankfurt Heidelberg Wolfsburg Bremen Ludwigshafen Köln Zwickau Koblenz Hamburg Mannheim Göttingen Berlin Stuttgart Hannover Andernach Aachen Bochum Bonn Ol Kiel Würzuburg Rügen IngolstadtComelio GmbH MS SQL Server: Grundlagen SOAP Webservices - MS SQL Server T-SQL XML Webservices Programmierung Bücher Anleitung Tutorial Skulschus Wiederstein Kozik XML Reporting .NET Webservices Server T-SQL Intelligence SQL Analysis Services Microsoft Bücher Business MS Lübeck Kassel Leipzig Erlangen Magdeburg Koblenz München Freiburg Frankfurt Heidelberg Wolfsburg Bremen Ludwigshafen Köln Zwickau Koblenz Hamburg Mannheim Göttingen Berlin Stuttgart Hannover Andernach Aachen Bochum Bonn Ol Kiel Würzuburg Rügen IngolstadtComelio GmbH MS SQL Server: Grundlagen SOAP Webservices - MS SQL Server T-SQL XML Webservices Programmierung Bücher Anleitung Tutorial Skulschus Wiederstein Kozik XML Reporting .NET Webservices Server T-SQL Intelligence SQL Analysis Services Microsoft Bücher Business MS Lübeck Kassel Leipzig Erlangen Magdeburg Koblenz München Freiburg Frankfurt Heidelberg Wolfsburg Bremen Ludwigshafen Köln Zwickau Koblenz Hamburg Mannheim Göttingen Berlin Stuttgart Hannover Andernach Aachen Bochum Bonn Ol Kiel Würzuburg Rügen IngolstadtComelio GmbH MS SQL Server: Grundlagen SOAP Webservices - MS SQL Server T-SQL XML Webservices Programmierung Bücher Anleitung Tutorial Skulschus Wiederstein Kozik XML Reporting .NET Webservices Server T-SQL Intelligence SQL Analysis Services Microsoft Bücher Business MS Lübeck Kassel Leipzig Erlangen Magdeburg Koblenz München Freiburg Frankfurt Heidelberg Wolfsburg Bremen Ludwigshafen Köln Zwickau Koblenz Hamburg Mannheim Göttingen Berlin Stuttgart Hannover Andernach Aachen Bochum Bonn Ol Kiel Würzuburg Rügen IngolstadtComelio GmbH MS SQL Server: Grundlagen SOAP Webservices - MS SQL Server T-SQL XML Webservices Programmierung Bücher Anleitung Tutorial Skulschus Wiederstein Kozik XML Reporting .NET Webservices Server T-SQL Intelligence SQL Analysis Services Microsoft Bücher Business MS Lübeck Kassel Leipzig Erlangen Magdeburg Koblenz München Freiburg Frankfurt Heidelberg Wolfsburg Bremen Ludwigshafen Köln Zwickau Koblenz Hamburg Mannheim Göttingen Berlin Stuttgart Hannover Andernach Aachen Bochum Bonn Ol Kiel Würzuburg Rügen Ingolstadt

SOAP

Kontakt

Das SOAP-XML-Format

Namensräume

Allgemeiner Aufbau

Batch-Anweisungen

WSDL

Standard-WSDL

Einfaches WSDL

Allgemeiner Aufbau

SOAP-Erweiterungen

Allgemeine Syntax