WebServices mit Microsoft.NET

Inhalt

1. Einleitung
1.1. Aufbau

2. Die Grundlagen
2.1..NET Framework
2.1.1. Zentrale Änderungen und Neuerungen des .NET-Frameworks
2.2. ASP.NET – Paradigma
2.2.1. Server Controls
2.2.2. OOP
2.2.3. Ablauf eines HTTP-Requestes
2.3. XML in .NET
2.3.1. Elemente und Attribute:
2.3.2. Namensräume
2.3.3. XML Schema
2.3.4. Lesen von XML-Dokumenten
2.3.5. Schreiben von XML-Dokumenten
2.3.6. Wichtige Klassen im Umgang mit XML-Dokumenten
2.4. SOAP
2.4.1. SOAP-Envelope
2.4.2. SOAP-Header
2.4.3. SOAP-Body
2.4.4. Fehlerbehandlung
2.4.5. Datenkodierung
2.4.6. HTTP-Binung
2.5. WSDL ( WebService Description Language )

3. Ein Web Services mit VS .Net
3.1. Das Ziel
3.2. Visual Studio .NET
3.3. Das Anlegen über VS.NET
3.4. Der erste Test
3.5. Die Verwendung in einem WebForm
3.5.1. Anbinden des WebService
3.5.2. Zugriff auf den WebService

4. .NET-Web-Service im Detail
4.1. Allgemeines zu ASP.NET WebServices
4.1.1. Aufbau und Ablauf
4.2. Grenzen der Web-Services
4.3. Übertragung binärer Objekte
4.4. Asynchrone Kommunikation
4.5. Sitzungsverwaltung

5. Ressourcen
5.1. WWW
5.1.1. W3C
5.1.2. Microsoft
5.1.3. Sonstige
5.2. Bücher und sonstige papiergebundene Literatur
5.3. Tools und Downloads

1. Einleitung

Durch den Performance-Schub der IT-Systeme in den letzten Jahren ist es endlich möglich die IT-Landschaft immer verteilter zu gestalten. Technologien wie SOAP währen bis vor 10 Jahren noch undenkbar und durch ein ‚effizienteres’, schnelleres proprietäres Format ersetzt worden. Doch erst der breitbandige Netzverkehr im Inter- sowie Intranet macht es möglich verwaltungslastige, aber flexiblere Datenformate zu verwenden.

In Zukunft wird dieser Trend wohl noch weiter gehen; und vermutlich werden zunächst WebServices etablieren.

Doch wozu benötigt man diese sogenannten ‚WebServices’?

Wie von der OOP gewohnt, ist man bestrebt in der Softwareentwicklung das Rad nicht immer neu erfinden zu müssen. Man greift somit auf verfügbare Frameworks und ToolKits zurück um produktiver arbeiten zu können.

Die Idee der WebServices ist hierzu nicht sehr unterschiedlich. Auch hier greift man auf ‚schon Vorhandenes’ zu.

Die Welt wird also auch in der Programmlogik immer ‚globalisierter’ und wohin der Trend geht, lässt sich nur erahnen.

1.1. Aufbau

In dieser Ausarbeitung zu .NET-WebServices werden zuerst Themen behandelt, die für WebServices allgemein die Grundlage darstellen. Es werden hier aber auch .NET-spezifische Themen behandelt, die aber wiede rum nicht nur für WebServices von Belang sind.

Nach diesen Grundlagen folgt eine detaillierte und praktische Beschreibung eines WebService, unter Verwendung von VisualStudio.NET. Dieser Teil bewusst wie ein Tutorial gehalten, ohne sich in den einzelnen Grundlagen-Details zu verlieren.

Nach diesem Praxisteil folgen Themen, die Materie speziell in der .NET-Welt erweitern. Hierbei wird auf das vorherige Beispiel immer wieder Bezug genommen.

2. Die Grundlagen

In diesem Kapitel werden die grundlegenden Technologien bzw. Standards vorgestellt und erklärt, deren Kenntnis zur Verwendung von WebServices wichtig sind.

Zum einen sind die hier erwähnten Technologien über die Grenzen der Netzdienste hinaus verwendbar, zum anderen handelt es sich um Standards, die neben Microsoft auch von anderen Herstellern unterstützt werden.

Im Bezug auf WebServices bauen einige Technologien aufeinander auf und lassen sich so als eine Art ‚Stapel’ darstellen. Hiermit werden auch die Zusammenhänge und das Zusammenspiel der einzelnen Schichten deutlicher.

Abbildung in dieser Leseprobe nicht enthalten

2.1.NET Framework

Seit Anfang 2002 ist das .NET-Framework für die Microsoft Plattformen in einer Final-Version verfügbar und hat die Entwicklung auf Microsoft-Plattformen stark beeinflusst.

In diesem Abschnitt will ich einen kurzen Einblick in die Struktur dieses relativ neuen Frameworks geben. Vieles wird dabei schon von der JAVA-Welt bekannt sein.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2 - .NET-Framework im Überblick

In Abbildung 2 erkennt man die einzelnen Komponenten des Frameworks.

Am auffallendsten wird wahrscheinlich sein, dass die unterstützten Programmiersprachen noch nicht komplett vorhanden sind. So werden diese momentan neben Mircosoft noch von anderen Herstellern umgesetzt. Diese müssen zwingend der CLS ( Common Language Specification ) entsprechen, um eine Zusammenarbeit mit den anderen Sprachen zu gewährleisten.

Diese CLS schränkt die Sprachen allerdings auch ein, so dass eine Portierung älterer Programmzeilen in das neue System nur bedingt möglich ist. Speziell zur Umsetzung der sprachspezifischen Typen muss hier der CTS ( Common Type Specification, ein Teil der CLS) genügen.

Durch diese Restriktion wird allerdings auch gewährleistet, dass zwischen den einzelnen Sprachen die erstellten Objekt-Klassen verwendet werden können.

Wie man sieht, sind die WebServices ausdrücklich aufgeführt und werden auch recht gut von der Klassen-Bibliothek unterstützt.

Neben den WinForms ( Oberflächenanwendungen die nicht zwingend eine Netzarchitektur benötigen. Stichwort: Rich-Client) hat, für verteilte Systeme, ASP.NET das etwas angestaubte ASP bzw. ASP+ abgelöst.

Als zentrale Komponente des Frameworks darf man aber, glaube ich, die CLR ( Common Language Runtime) bezeichnen, die der JVM ( JAVA Virtual Machine ) sehr ähnlich ist.

Doch dazu später mehr.

Für die einzelnen Programmiersprachen gibt es jeweils eigene Compiler. Einige davon liefert Microsoft schon mit. Diese sind allerdings im .NET-Framework-SDK (Software Development Kit) nur als Kommandozeilencompiler verfügbar.

Nehmen wir ein Beispielprogramm, das in C# umgesetzt wurde.

Abbildung in dieser Leseprobe nicht enthalten

Nach dem Kompilieren erhalten wir ein so genanntes Assembly. Dieses Assembly sieht im Explorer aus wie eine normale DLL, doch ist das nur von außen betrachtet so.

Innerhalb haben wir den kompilierten MSIL-Code (Microsoft Intermediate Language) und das Manifest (eine Art ‚Beipackzettel’). MSIL-Code, der über die CLR ausgefüht wird, nennt man auch ‚Managed Code’.

Dies sind die Grundkomponenten die jedes Assembly beinhaltet. Darüber hinaus können aber Ressource-Daten, wie etwa Bilddateien direkt vorhanden sein. Im Falle einer Web-Applikation werden diese direkt vom WebServer und nicht über die Laufzeitumgebung geladen.

Es gibt jedoch auch die Möglichkeit, auf andere Assemblies zu referenzieren, sowie ‚externe’ Ressourcen zu verwenden.

Der Inhalt eines Assemblies lässt sich am einfachsten über das Tool ildasm.exe betrachten. Dies ist im SDK enthalten.

Beim Ausführen eines Assemblies wird dieses von der CLR geladen, über einen JIT-Kompiler (Just In Time) in systemverständlichen Code umgewandelt und anschließend zum Ausführen gebracht.

Es wird zusätzlich im GAC (Global Assembly Cache) überprüft, ob bereits eine ausführbare Version vorliegt. Wenn nicht wird der MSIL-Code dort hinterlegt.

Dieses Vorgehen bringt einen enormen Geschwindigkeitsschub mit sich.

2.1.1. Zentrale Änderungen und Neuerungen des .NET-Frameworks

Zusammenfassend haben sich für den .NET-Entwickler unter anderem folgende Neuerungen ergeben:

- Anwendungen registrieren sich nicht mehr in der zentralen Registry.
Als Ersatz kann hier der GAC gesehen werden. Der GAC kann jedoch nicht nur verschiedene Versionen eines Assemblies beinhalten, sondern beherrscht es auch, die Assemblies anhand kulturellen Kriterien, wie etwa Sprache zu unterscheiden. Das Ende der ‚DLL-Hölle’^[1] ist somit eingeleitet und sollte in zukünftigen Windows-Betriebssystemen immer weniger ein Problem darstellen.
- Für ein und dieselbe Anwendung können mehrere Sprachen verwendet werden. Da alle Sprachen zu einer ‚Zwischen’-Sprache (IL) kompiliert werden, die wiederum duch dieselbe CLR ausgeführt wird, entstehen nur marginale Geschwindigkeitsunterschiede.
- Die CLR bzw. der JIT-Kompiler kann aus IL-Code, auf die jeweiligen Zielsysteme optimierten, Byte-Code erzeugen, was einen zusätzlichen Performanceschub ermöglicht.
- Die Entwicklung auf Server- und Clientsystemen ist annähernd identisch.
- Da ASP.NET-Seiten (WebForms) vorkompiliert werden, sind Geschwindigkeitssteigerungen von 200-300% möglich.
- Der Funktionsumfang des Frameworks hat sich im Vergleich zur bisherigen MFC (Microsoft Foundation Classes) deutlich erhöht.
- Eine umfassende XML-Unterstützung zieht sich durch die komplette Klassenbibliothek.
- ADO wurde von ADO.NET abgelöst, das jetzt durchgängig XML unterstützt und weitere Datenbankabfragemöglichkeiten ermöglicht.

2.2. ASP.NET – Paradigma

In diesem Abschnitt soll ein kurzer Einblick in die Vorgehensweise und Anwendung des neuen ASP.NET-Konzepts gegeben werden.

Das neue ASP.NET hat umfassende Änderungen erfahren und verdient eigentlich eine komplett neue Bezeichnung. Anwendungen die auf ASP.NET aufbauen nennt Microsoft ‚WebForms’, im Gegensatz zu Windows-Anwendungen, die ‚WinForm’ genannt werden.

Der auffälligste Unterschied gegenüber dem ‚alten’ ASP, ist die Trennung von Design und Programmlogik. Diese zwei Aspekte können konkret in zwei unterschiedlichen Dateien repräsentiert werden. Es ist somit möglich eine Arbeitskraft nur auf das Oberflächendesign anzusetzen und parallel dazu einen anderen Mitarbeiter die verwendete Programmlogik entwickeln zu lassen.

In der Praxis sieht das aber eher so aus, dass die ASP.NET-Entwicklung in zwei Phasen geschieht:

- Design-Phase (Fokus liegt auf der ASPX-Datei, autom. Gen. der CodeBehind-Datei^[2] )
- Implementierungs-Phase (Fokus liegt auf der CodeBehind-Datei, Programmlogik )

Abbildung in dieser Leseprobe nicht enthalten

Natürlich sind Designnachbesserungen nicht immer zu vermeiden.

Da ASP.NET auch auf dem .NET-Framework mit der CLR (s.Kapitel 2.1) aufbaut, sind hier für die CodeBehind-Datei unterschiedliche Programmiersprachen verwendbar. Es ist denkbar, dass in einem Projekt mit mehreren ASP.NET-Dateien unterschiedliche Sprachen verwendet werden. So kann man sich folgendes Szenario vorstellen: Eine Webseite ist in 3 Frames^[3] eingeteilt. Oben sei die Navigation, rechts ein paar News und links der eigentliche Kontext-Bereich. Es währe nun denkbar, dass zur Navigation C#, für die News VB.NET und für den Kontext-Bereich J# zum Einsatz kommen. Die Programmlogik kann auch direkt in der ASPX-Datei stehen (inline), was man aber vermeiden sollte.(s.o.)

2.2.1. Server Controls

ServerContols sind die Bausteine einer ASP.NET-Seite und lassen sich grob in zwei Rubriken teilen:

- HTML-Controls und
- ASP-Controls.

Vorteil der ASP-Controls ist, dass ein komplexer Aufbau dahinter stehen kann, der sich clientseitig in einem umfassenden HTML- oder sogar JavaScript-Block bemerkbar macht.

Ein ServerControl muss als Attribute ‚ runat=“server“ ’ und eine ID-Bezeichnung haben um von der CodeBehind-Seite aus verwendbar zu sein. Die ID-Bezeichnung muss hierbei dem Control-Bezeichner des Controls der CodeBehind-Seite entsprechen.

Beispiel aus Kapitel 3.5:

- Instantziierung auf der ASP.NET-Seite:
<asp:Label id="Label1"
style="Z-INDEX: 101; LEFT: 34px; POSITION: absolute; TOP: 35px"
runat="server"> Betrag
</asp:Label>
- Deklaration auf der CodeBehind-Seite:
protected System.Web.UI.WebControls.Label Label1;

Server Controls können selbst erstellt werden und im Sinne der OOP hierarchisch vererb, oder von schon bestehenden Controls abgeleitet werden. Erkennbar sind eigene Controls an der Dateiendung ‚ascx’.

Am sinnvollsten sind ServerControls bei Formular-Elementen, da hier meist eine serverseitige Verarbeitung der eingegebenen Daten erforderlich ist.

2.2.2. OOP

Mit ASP.NET kann man streng objektorientiert programmieren. Selbst wenn einem dies nicht auffällt, wird dies oft automatisch von der ASP.NET-Runtime übernommen.

Zum Beispiel wird beim Kompilieren eines Projektes das mit Code-Behind-Dateien arbeitet erst nur die CodeBehind-Datei übersetzt. Die Klasse, die in der CodeBehind-Datei definiert wird, muss immer von System.Web.UI.Page abgeleitet sein.

Über diese CodeBehind-Datei wird eine Klasse erzeugt, die zur Laufzeit von der ASPX-Datei erweitert wird. So ist auch zu erklären, warum die verwendeten ServerControls in der CodeBehind-Datei nur als Deklaration vorhanden sind und den Zugriffsmodifier ‚ protected ’ haben. Die eigentliche Instanziierung der ServerControls findet erst zur Laufzeit statt.

2.2.3. Ablauf eines HTTP-Requestes

Wie sieht nun eine konkrete Abfrage aus?

Ein Client stellt eine Anfrage über HTTP an den WebSever (z.B. IIS), dieser erkennt anhand der URL (z.B. Dateierweiterung . aspx), dass es sich um eine APS.NET-Anfrage handelt. Er wird nun diese Anfrage an die ASP.NET-Laufzeitumgebung weiterleiten. Diese interpretiert die Anfrage und der Just-In-Time Compiler kompiliert ggf. die betroffenen ASP.NET-Komponenten. Diese werden dann serverseitig von der Laufzeitumgebung zur Ausführung gebracht. Entsprechend der Programmlogik wird durch die Laufzeitumgebung der HTML-Output generiert und an den Webserver weitergegeben, der diesen via HTTP zum Aufrufenden Client schickt.

2.3. XML in .NET

WebServices sind, wie andere verteilte Systeme, abhängig von den Möglichkeiten der Kommunikation zwischen den einzelnen Stationen. XML hat sich in den letzten Jahren als Standard etabliert und bewährt. Umso wichtiger ist es, grundlegende Kenntnisse über dieses Kommunikationsmittel zu besitzen, das im Weiteren auch die Basis für weitere Techniken, wie etwa SOAP (s.Kapitel 2.4), darstellt.

Wie andere Hersteller, setzt Microsoft, bei der Einführung des Frameworks, auf den Standard XML. Durch XML liegt vor allem eine textuelle Form des Austauschs von Daten und Dokumenten vor.

Ein Dokument kann gemäß der XML-Spezifikation aus mehreren syntaktischen Konstrukten bestehen, die im einzelnen kurz vorgestellt und erläutert werden.

2.3.1. Elemente und Attribute:

Am Anfang eines XML-Dokuments steht normalerweise die XML-Deklaration, die aber nicht zwingend vorgeschrieben ist.

Abbildung in dieser Leseprobe nicht enthalten

Aus dem Beispiel erkennt man die Kennzeichner (Tags), welche die eigentliche Information umschließen. Jeder Tag muss, ähnlich einer Klammer, geschlossen werden. Merkmal hier ist der Slash vor dem Tag-Bezeichner. Falls leere Elemente benötigt werden, kann auf den schließenden Tag verzichtet werden und alternativ vor dem ‚>’ einen Slash setzen.

Abbildung in dieser Leseprobe nicht enthalten

Von der Art der Modellierung hängt es ab, ob man einen bestimmten Sachverhalt durch Attribute, oder Elemente darstellt. Diese Frage lässt sich oft nur abhängig vom gegebenen Anwendungsfall beantworten.

2.3.2. Namensräume

Jedes Element muss in XML eindeutig sein. Da Element-Bezeichner aber frei verwendet werden können, kann es bei unterschiedlichen Benutzern zu Mehrdeutigkeiten kommen. Um dies zu vermeiden, führte man XML-Namensräume ein, in denen die einzelnen Elemente liegen.

Namensräume werden durch Angabe eines URI (Uniform Resource Identifier) festgelegt.

Der Bezeichner des Namensraumes muss, getrennt durch einen Doppelpunkt, immer vor dem Elementbezeichner stehen (Präfix-Notation).

Abbildung in dieser Leseprobe nicht enthalten

Neben den explizit benannten Namensräumen kann man auch noch einen standardmäßigen Namensraum für ein Element angeben. Vorteil hier ist, dass die Kindelemente den selben Namensraum ‚erben’ und nicht weiter zugewiesen werden müssen.

Abbildung in dieser Leseprobe nicht enthalten

2.3.3. XML Schema

XML alleine reicht leider noch nicht aus, um einen reibungslosen Datenaustausch zu gewährleisten. Unterschiedliche XML-Entwickler können für das selbe Dokument unterschiedliche Strukturen entwerfen. Um eine syntaktische wie auch semantische Korrektheit zu gewährleisten, ist eine weitere Technologie notwendig. Ursprünglich war hierfür eine DTD-Datei (Dokument Type Definition) zuständig, die in einer eigenen Sprache entwickelt wurde und selbst nicht auf XML basierte.

Seit Mai. 2001 wurde DTD endgültig von den XML-Schemata abgelöst.

XML-Schemata erlauben folgende Überprüfungen:

- Die Struktur von Elementen und Attributen,
- Die Reihenfolge der Elemente,
- Die Datenwerte der Elemente und Attribute, abhängig von Wertbereichen, Aufzählungen und ‚Pattern-Matching’,
- Die Eindeutigkeit der Werte.

Folgendes Beispiel überprüft den obigen XML-Ausschnitt auf Korrektheit:

Abbildung in dieser Leseprobe nicht enthalten

2.3.4. Lesen von XML-Dokumenten

Es gibt zwei Möglichkeiten in .NET XML-Dokumente zu lesen.

1. Über XmlDocument (W3C DOM angelehnt),
2. durch Implementierung eines XmlReader.

Abbildung in dieser Leseprobe nicht enthalten

[...]

---

^[1] DLL-Hölle: In herkömmlichen Windows-Betriebssystemen konnte nur eine Version einer DLL (Komponenten Bibliothek) zentral registriert werden. Eine Anwendung installiert nun eine Version einer DLL V1. Eine andere Anwendung braucht aber die selbe DLL in der Version V2. Sie ersetzt die alte DLL mit der neuen, die allerdings nicht mehr alle Funktionen enthält. Es kann somit sein, dass die erstere Anwendung nicht mehr lauffähig ist. Diese und andere damit zusammenhängende Effekte werden DLL-Hölle bezeichnet.

^[2] Eine CodeBehind-Datei enthält die Klassendefinition der Seite. Der Compiler erzeugt aus dieser Datei eine Klasse in MSIL. Zur Laufzeit wird diese Klasse durch die Angaben der ASPX-Datei erweitert. Falls die Programmlogik direkt in der ASPX-Datei steht (inline), wird dieser Code während des Kompilierens extrahiert und entspr. verfahren.

^[3] Eine Möglichkeit eine Darstellung aufzuteilen; HTML-basiert.