Dietmar Theinert

1. EINLEITUNG

1.1. Aufbau

2. DIE GRUNDLAGEN 4 2.1. .NET Framework 4 2.1.1. 2.2. ASP.NET - Paradigma 2.2.1. 2.2.2. 2.2.3. 2.3. XML in .NET 2.3.1. 2.3.2. 2.3.3. 2.3.4. 2.3.5. 2.3.6. 2.4. SOAP 2.4.1.

2.4.2. 2.4.3. 2.4.4. 2.4.5. 2.4.6. 2.5.

WSDL ( WebService Description Language ) 18 3. EIN WEB SERVICES MIT VS .NET

3.1. Das Ziel 3.2.

Visual Studio .NET 23 3.3. Das Anlegen über VS.NET 23 3.4.

Der erste Test 29 3.5. Die Verwendung in einem WebForm

3.5.1. 3.5.2. 4. .NET-WEB-SERVICE IM DETAIL 35

4.1. Allgemeines zu ASP.NET WebServices 4.1.1. 4.2.

Grenzen der Web-Services 37 4.3. Übertragung binärer Objekte 38

4.4. Asynchrone Kommunikation 40 4.5. Sitzungsverwaltung 42

5. RESSOURCEN

5.1. WWW 5.1.1.

5.1.2. 5.1.3.

5.2. Bücher und sonstige papiergebundene Literatur 5.3. Tools und Downloads 44

Dietmar Theinert

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.

Dietmar Theinert

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.

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.

Dietmar Theinert

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.

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. I m 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 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.

Dietmar Theinert

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’ ¹ 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.

¹ 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.

Dietmar Theinert

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

• Implementierungs-Phase

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 ³ 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.

² 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.

³ Eine Möglichkeit eine Darstellung aufzuteilen; HTML-basiert.

Dietmar Theinert

Beispiel aus Kapitel 3.5:

• Instantziierung auf der ASP.NET-Seite:

• 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 Compiler betroffenen ASP.NET-Komponenten. Diese werden dann serverseitig von der Laufzeitumgebung zur Ausführung gebracht. Programmlogik wird durch die Laufzeitumgebung der HTML-Output Abbildung 3 - Der ASP.NETSeitenaufruf generiert und an den Webserver weitergegeben, der diesen via HTTP zum Aufrufenden Client schickt.

Dietmar Theinert

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.

Beispiel:

Der 'eigentliche' Inhalt eines Dokumentes bildet allerdings die sogenannten Elemente, die die grundlegende Struktur festlegen. Jedes Dokument hat genau ein Element höchster Stufe, das Dokumentenelement. Die Elemente können beliebig viele Kindelemente haben, die wiederum selbst Kindelemente haben können.

Beispiel ohne und mit Kindelement:

Dietmar Theinert

Theinert Dietmar

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.

Beispiel:

Innerhalb eines Tags (<...>) können zusätzlich Attribute definiert werden.

Diese Attribute liefern zusätzliche Informationen zu dem Element und werden als Name/Wert-Paar dargestellt.

Beispiel:

Theinert Dietmar