Webservices und das .NET-Framework · PDF fileSo kann z.B. ein in C# geschriebener Webservice...

Komponentenbasierte Softwareentwicklung

Webservicesund das

.NET-Framework

von Sebastian Ahlers & Daniel Bonk

Webservices mit .NET

Sebastian Ahlers & Daniel Bonk Seite 2

1. Microsoft .NET .............................................................................................................. 31.1. Was ist .NET? ........................................................................................................ 31.2. Microsoft .NET Sprachen ...................................................................................... 3

2. Webservice ..................................................................................................................... 42.1. Was ist ein Webservice? ........................................................................................ 42.2. Architektur und Rollenverteilung........................................................................... 52.3. Beispiele ................................................................................................................. 5

3. SOAP.............................................................................................................................. 73.1. Was ist SOAP? ....................................................................................................... 73.2. Aufbau einer SOAP-Nachricht............................................................................... 73.3. SOAP Vorteile........................................................................................................ 83.4. SOAP Nachteile ..................................................................................................... 8

4. WSDL............................................................................................................................. 94.1. Was ist WSDL?...................................................................................................... 94.2. Beschreibungselemente.......................................................................................... 9

5. UDDI............................................................................................................................ 105.1. Was ist UDDI? ..................................................................................................... 105.2. Beispielszenario Buchhandel ............................................................................... 10

6. Webservice-Tutorial..................................................................................................... 146.1. Webservice erstellen mit Microsoft Visual Studio 2005 ..................................... 146.2. Webservice über Microsoft IIS bereitstellen........................................................ 146.3. Webclient erstellen mit Microsoft Visual Studio 2005........................................ 15

7. Webservice-Beispiel..................................................................................................... 167.1. SemesterTimeService........................................................................................... 167.2. SemesterTimeClient ............................................................................................. 17

8. Quellenangaben............................................................................................................ 18



1. Microsoft .NET

1.1. Was ist .NET?.NET ist eine Laufzeitumgebung und eine Sammlung (Framework) von Klassenbibliotheken. Es wurde von Microsoft entwickelt und im Jahre 2002 in der Version 1 veröffentlich. Zur Entwicklung von .NET kam es Dank eines Rechtsstreits zwischen Microsoft und SUN um die Weiterentwicklung von Java seitens Microsoft. Nachdem SUN eine Unterlassung erwirkt hatte, begann Microsoft, seine eigene Umgebung zu entwerfen. Dies erklärt vielleicht auch die große Ähnlichkeit zwischen Java und .NET. So besitzen beide einen Zwischencode in dem die Programm übersetzt werden. Dieser Zwischencode heißt bei .NET Common Intermediate Language (CIL).

Wie bei Java wird auch eine virtuelle Maschine zum Ausführen benutzt, die Common Language Runtime(CLR). Weil Microsoft aber besonderen Wert auf Geschwindigkeit gelegt hat, gibt es bei der virtuellen Maschine auch einen Unterschied in der Arbeitsweise. So wird CIL Code zur Laufzeit in Maschinencode übersetzt, wodurch ein Geschwindigkeitsvorteil gegenüber Java erreicht wird.

.NET gilt als plattformunabhängig, was aber nur bedingt stimmt, weil Microsoft nur sein eigenes Betriebssystem (Windows) unterstützt. Es gibt aber auch Projekte, die .NET auf anderen Betriebssystemen lauffähig machen. So gibt es z.B. das Projekt Mono von NOVELL oder das OpenSource Projekt Portable.NET, die .NET unter Unix, Linux, Mac OS X und Solaris 8 anbieten. Dies ist möglich, weil .NET, wie auch die .NET Sprache C#, von der ECMA standardisiert worden ist.

Mit einer der größten Vorteile von .NET ist wohl die Sprachunabhängigkeit. .NET unterstützt eine Vielzahl von Sprachen, unter anderem C++, VB, C# oder J#. So können Komponenten in unterschiedlichen Programmiersprachen entwickelt werden und zusammen in einer Anwendung funktionieren. Dies gelingt durch das Common Type System, ein vereinheitlichtes Typsystem für alle .NET Sprachen. Man kann es sich als Schnittmenge von Datentypen vorstellen.

1.2. Microsoft .NET Sprachen Basic

C#

C++

Java

Modula-2

Pascal

PHP

Phyton

Smalltalk

und viele andere



2. Webservice

2.1. Was ist ein Webservice?Ein Webservice ist eine Software-Komponente, die über das Web veröffentlicht, gefunden und aufgerufen werden kann.

Das Ziel ist, Applikationen die Kommunikation über das World Wide Web zu ermöglichen. Die bisher im Web vorherrschende Mensch-Maschine-Kommunikation (Mensch ruft mit einem Browser Informationen von einem Server ab) wird von Webservices um Maschine-Maschine-Kommunikation ergänzt (Applikationen unterhalten sich untereinander über das Web). Die Vorteile von solchen verteilten Systemen sind, dass sich Ressourcen dezentralisieren lassen und spezielle Hardware gemeinsam genutzt werden kann. Da Webservices Komponenten sind, erben sie auch deren Vorteile: Wiederverwendbarkeit, Kapselung, lose Kopplung, etc.

Webservices basieren auf den drei Standards SOAP, WSDL und UDDI. Das sind vom W3C standardisierte XML-Spezifikationen. XML ist für Webservices besonders gut geeignet, weil Struktur, Inhalt und Form getrennt sind, es einfach erweiterbar und weit verbreitet ist. SOAP sorgt für die Kommunikation zwischen Service-Anbieter und Service-Konsument, WSDL beschreibt die Schnittstellen des Webservices und mit UDDI lassen sich Verzeichnisse erstellen, in denen Service-Anbieter Services eintragen können und in denen Service-Konsumenten nach Services suchen können.

Webservices sind plattformunbhängig. Das bedeutet, dass als Service-Anbieter oder Service-Konsument fast jedes kommunikationsfähige Gerät in Frage kommt, wie z.B. Handy, PDA, PC, aber auch exotischere Plattformen wie Colaautomat oder Parkuhr.

Webservices sind programmiersprachenunabhängig. So kann z.B. ein in C# geschriebener Webservice auf einem Microsoft IIS oder ein in Java geschriebener Webservice in einem Servlet-Container eines Apache Tomcat laufen. Es sind auch viele andere Kombinationen denkbar. Auch auf der Clientseite ist man bei der Wahl der Programmiersprache fast völlig frei. Es muss nur die Möglichkeit geben, über eine Netzwerkverbindung in den bereits genannten XML-Sprachen kommunizieren zu können.

Webservices bieten eine protokollunabhängige Kommunikation. Man kann auf sie über Standard-Internetprotokolle zugreifen. Das ist meistens HTTP, aber auch SMTP, FTP, etc. sind denkbar. Die SOAP-Nachrichten werden in diese Protokolle einfach eingebettet. Durch die freie Protokollwahl kann man z.B. Problemen mit Firewalls aus dem Weg gehen. Man erreicht eine einfache Bereitstellung und eine hohe Verfügbarkeit.

Webservices sind selbstbeschreibend. Das heißt, dass ein Webservice von Meta-Daten (Daten über Daten) begleitet wird, die in maschinenlesbarer, standardisierter Form beschreiben, wie der Service genutzt werden kann. So lässt sich das Zusammenfügen von Webservices zu Komponentensystemen in vielen Fällen automatisieren.



2.2. Architektur und RollenverteilungDie Webservice-Architektur ist in drei Rollen eingeteilt:

Service Broker

Service Konsument Service Anbieter

suche Service

WSDL

beschreibt denService

zeigt auf Service

zeigt auf Beschreibung

SOAP

UDDI

Der Service Anbieter bietet einen Service über das Web an. Er beschreibt ihn mit WSDL und annonciert ihn bei einem UDDI-Server. Er übernimmt die Implementierung, den Betrieb und die Wartung des Services.

Der Service Konsument sucht auf einem UDDI-Server Services nach gewissen Kriterien und nutzt die angebotenen Services über SOAP.

Der Service Broker bietet die Speicherung von Verweisen auf Servicebeschreibungen an und verwaltet kategorisierte Servicebeschreibungen. Er ermöglicht das automatische Auffinden von gespeicherten Services.

2.3. BeispieleEs gibt zum einen so genannte Komponentendienste, die nur aus einem Webservice bestehen:

Währungsumrechnung

Übersetzungen

Überprüfung von Kreditkarten

Börsenkurse

Frachtverfolgung

Flug- und Bahnpläne

Authorisierungsdienste



Websuche (z.B. Google)

etc.

Des Weiteren gibt es so genannte zusammengesetzte Dienste, die mehrere kleine Dienste zu einem großen Dienst zusammensetzen:

Reisebuchung

Buchhandel (siehe unten)

Reklamationsbearbeitung

etc.



3. SOAP

3.1. Was ist SOAP?SOAP stand ursprünglich für Simple Object Access Protocol, was sich aber im Laufe der Zeit geändert hat, weil Simple Object Access Protocol nicht den vollen Umfang von SOAP beschreibt. Heute ist SOAP ein eigenständiger Name. SOAP wurde von der W3Cstandardisiert und ist ein XML-basierendes Protokoll zum Austausch von Daten zwischen Systemen und kann genutzt werden, um Remote Procedure Calls auszuführen. Die Nutzung von XML ist auch die größte Schwäche von SOAP, weil durch das Benutzen von XML die Datenmengen sehr viel größer werden. Um bei SOAP Binärdaten zu übertragen, wird MIME benutzt und die Daten werden an die SOAP Nachricht – ähnlich einer Email – angehangen.

SOAP ist transportprotokollunabhängig, dass heißt, SOAP kann über unterschiedlichste Transportprotokolle betrieben werden, z.B. SMTP/POP3. Es wird aber hauptsächlich HTTP oder HTTPS eingesetzt. Durch den Einsatz von HTTP als Transportprotokoll ist es SOAP möglich, auch durch die meisten Firewalls zu kommunizieren.

Desweiteren ist SOAP plattformunabhängig und kann somit unabhängig vom Betriebssystem eingesetzt werden, was bei der Nutzung über das Internet einen großen Vorteil darstellt.

Auch die Programmiersprachenunabhangigkeit hilft SOAP, sich langsam als der Standard für Webservices durchzusetzen. So basiert nicht nur Microsoft mit dem .NET Webservice auf SOAP sondern auch Java und andere Sprachen unterstützen SOAP oder können es leicht implementieren und dann SOAP unterstützen.

3.2. Aufbau einer SOAP-NachrichtEine SOAP Nachricht ist wie ein Brief aufgebaut. Sie besitzt einen Umschlag (Envelope),einen optionalen Header mit Daten über das Routing oder Authentifizierung und einen Body,in dem die eigentlichen Nutzdaten enthalten sind.

Hier ein Beispiel für eine SOAP Nachricht:

<?xml version="1.0" encoding="UTF-8"?>+------------------------------------------------SOAP-Envelope--+| <SOAP-ENV:Envelope || xmlns:SOAP-ENV="http://..." || ... || +-----------------------------------SOAP-Header (optional)--+ || | <SOAP-ENV:Header> | || | <t:transaction | || | xmlns:t="..." ... | || | </SOAP-ENV:Header> | || +-----------------------------------------------------------+ || +------------------------------------------------SOAP-Body--+ || | <SOAP-ENV:Body> | || | <m:getLastTradePrice xmlns:m="trading-uri"> | || | <ticker>SUNW</ticker> | || | </m:getLastTradePrice> | || | </SOAP-ENV:Body> | || +-----------------------------------------------------------+ || </SOAP-ENV:Envelope> |+---------------------------------------------------------------+



3.3. SOAP Vorteile plattformunabhängig

programmiersprachenunabhängig

standardisiert

transportprotokollunabhängig

3.4. SOAP Nachteile mehr Daten durch XML-Aufbau von SOAP



4. WSDL

4.1. Was ist WSDL?WSDL (sprich engl.: "wiz-dull") steht für Webservice Description Language. Es ist, wie SOAP, eine vom W3C standardisierte XML-Spezifikation. Mit ihr wird zum einenbeschrieben, was ein Service für eine Funktionalität anbietet und zum anderen, wie er diese Funktionalität anbietet.

Das "wie" entspricht der Spezifikation von Schnittstellen und Transportprotokollen. Schnittstellen müssen genau bekannt sein, damit sich Webservices reibungslos zu einem Komponentensystem zusammensetzen lassen. Die Schnittstellenbeschreibungen können außerdem wie ein Vertrag zwischen Service-Anbieter und Service-Konsument aufgefassenwerden, denn sie sichern eine bestimmte Leistung zu.

Da die WSDL-Dokumente standardisiert und maschinenlesbar sind, können Komponentensysteme selbstständig neue Services einbinden. Es gibt die Vision eines "Automated Web", in dem Geschäftsprozesse ohne Steuerung durch den Menschen ablaufen können. Das Problem dabei: es fehlen Aussagen über Preise, Lieferbedingungen (z.B. die Zeit), rechtliche Aspekte (z.B. Nichterfüllung einer Lieferung), Entwicklungsgrad, Verfügbarkeit der Services, etc. Maschinen sind nicht intelligent genug, diese Probleme ohne menschliche Hilfe zu lösen.

4.2. BeschreibungselementeEin WSDL-Dokument besteht aus verschiedenen Beschreibungselementen:

<portType> ist eine Sammlung von Funktionen oder Operationen, die der Webservice anbietet. Es gibt 4 Arten:

o one-way: Client sendet Nachricht an Server

o notification: Server sendet Nachricht an Client

o request-response: Anfrage eines Clients mit Antwort vom Server

o solicit-response: Anfrage eines Servers mit Antwort vom Client

<message> beschreibt die einzelnen SOAP-Nachrichten (Anfragen und Antworten) und die dabei übergebenen Parameter

<types> beschreibt alle Datentypen, die beim Datenaustausch zwischen Service-Anbieter und Service-Konsument verwendet werden

<binding> beschreibt, wie Informationen übermittelt werden sollen (z.B. HTTP POST, HTTP GET)

<port> gibt die Adresse, unter der der Webservice erreichbar ist in Form einer URI an

<service> stellt eine Sammlung von Ports dar

Um die Bedeutung der einzelnen Elemente besser zu verstehen, kann man sie mit Elementen aus der klassischen Programmierung (z.B. Programmiersprache C) vergleichen: PortTypes entsprechen einer Funktionsbibliothek, Messages entsprechen Funktionsparametern und Types entsprechen Typdefinitionen.



5. UDDI

5.1. Was ist UDDI?UDDI steht für Universal Description, Discovery and Integration und ist ein Verzeichnisdienst. Man kann ihn vergleichen mit den bekannten gelben Seiten. Genau wie bei der Papierform tragen Firmen ihre Branche und ihre Addressen ein. Der Vorteil zum gedruckten Vorbild ist aber das man bei einem UDDI Verzeichnisdienst auch Services direkt über das Netzwerk (z.B. Internet) anbieten und nutzen kann. Firmen und ihre Services können auf dem UDDI Server gesucht werden und können dann zur Laufzeit in Programmen oder Webseiten von anderen Firmen eingebunden werden (siehe unten: Beispielszenario Buchhandel). Dieses ermöglicht Firmen schnellen und aktuellen austausch von Komponenten und Daten, was in Business 2 Business Lösungen immer wichtiger wird.

5.2. Beispielszenario BuchhandelIn diesem Abschnitt werden wir Ihnen ein Beispielszenario zeigen, um Ihnen die Strukturen und die Vorteile des Einsatzes eines UDDI Service Broker zu zeigen.

Unser Beispielszenario dreht sich um einen Buchhandel. Dieser Buchhandel möchte ein Programm entwickeln lassen, was alle Bücher der verschieden Verlage anbietet, auflistet und die Bestellung realisiert. Man könnte jetzt natürlich eine Datenbank anlegen, in der alle Bücher der verschieden Verlage aufgelistet und dann über ein Fax bestellt werden. Doch müsste man andauert Datensätze hinzufügen und verändern, um immer auf dem neusten Stand zu sein. Warum nicht direkt den Verlag fragen, was er für Bücher im Sortiment hat? Und was passiert, wenn ein neuer Verlag hinzukommt? Dann müsste man womöglich 100 oder mehr Bücher einfügen. Um diesen Aufwand für den Buchhandel zu verringern, benutzen wir einen UDDI Service Broker. Im folgenden werden wir schrittweise durchgehen und Ihnen den möglichen Ablauf erklären.



1. Schritt – Branchen und Services suchen

Als erstes verbinden wir uns mit einem UDDI Server und suchen nach der Branche "Verlag", wodurch wir eine Liste aller Verlage erhalten (in unserem Beispiel Verlag A und B). Dann suchen wir, ob die Verlage einen Webservice "Bücherliste" anbieten (siehe Abbildung 5.1). Dieser Service bietet uns die Möglichkeit, eine komplette Liste alle Bücher des Verlages zu erhalten. Somit geben wir das Einpflegen und Warten der Datensätze an den Verlag ab und haben immer eine aktuelle Liste aller Bücher.

A

B

Verlage

Service Broker

Service suchen "Bücherliste"Buchhandel

UDDI

Abbildung 5-1: Aufbau des Beispielszenarios

2. Schritt – Services aufrufen

Als nächstes holen wir die Listen der Bücher in unser Programm. Diese geschieht über den Aufruf des SOAP-Webservices "Bücherliste" beim Verlag A bzw. Verlag B. Jetzt haben wir den ersten Teil der Aufgabe schon erfüllt, eine wartungsfreie, aktuelle Liste alle Bücher1 der verschiedenen Verlage.

Buchhandel

A

B

Verlage

Bücher-liste

Bücher-liste

Abbildung 5-2: Webservices aufrufen

1 Solange der Verlag eine aktuelle Liste der Bücher anbietet



3. Schritt – Buch bestellen bei Verlag A

In Schritt 3 wollen wir uns den Verlag A mal genauer anschauen. Wie oben schon erklärt, ist UDDI vergleichbar mit den gelben Seiten und zum Verlag A stehen folgende Daten bereit. (siehe Abbildung 5.3). Die Adresse des Verlages und die Faxnummer. Desweiteren sagt uns UDDI, welche Services Verlag A anbietet. Den schon benutzten Webservice "Bücherliste" und den Webservice "Online bestellen". Und genau den werden wir jetzt nutzen um eine Buch bei Verlag A zu bestellen. Wie auch schon bei dem Service "Bücherliste" rufen wir den "Online bestellen" Service auf, übergeben in diesem Fall aber Parameter2 und erhalten eine Erfolgsnachricht zurück. Und schon ist das Buch bestellt.

Buchhandel

ADaten: Adresse Telefax

Services: Bücherliste Online bestellen

Webservices Aufruf "Online bestellen"

Abbildung 5-3: Buchbestellung bei Verlag A

4. Schritt – Buch bestellen bei Verlag B

Wie bei Schritt 3 schauen wir uns die Daten von Verlag B an. Zu unserem Bedauern hat Verlag B leider keinen Webservice "Online bestellen". Somit müssen wir einen anderen Weg finden, das Buch zu bestellen. Wir haben bei Verlag B auch eine Faxnummer bei den Daten stehen (siehe Abbildung 5.4). Nur wie verschicken wir nun ein Fax? Genau da kann ein UDDI Service Broker wieder helfen. Wir suchen auf dem Server nach einem Service "Fax" und fragen die Faxnummer des Verlages B ab. Jetzt müssen wir nur noch alles zusammenfügen und dies geschieht im Schritt 5.

Buchhandel

BDaten: Adresse Telefax

Services: Bücherliste

Service Broker

Faxnummer erfragen und erhalten

Service suchen "Fax"

UDDI

Abbildung 5-4: Buchbestellung bei Verlag B

2 Parameter könnten z.B. Händlernummer und ISBN Nummer sein



5. Schritt – Faxen

Wir erhalten vom UDDI Server einen "Fax" Service. Diesem übergeben wir wieder verschiedene Parameter und natürlich die Faxnummer und schicken das über den "Fax" Service Anbieter an den Verlag B. Jetzt kann der Verlag B auch die Bestellung verarbeiten und wir müssen nur noch warten bis das Buch bei uns in der Buchhandlung eintrifft.

Buchhandel

Service Broker

"Fax" Service erhalten

"Fax" Service Anbieter

Bestellfax an Verlag B

UDDI

Abbildung 5-5: Faxen

Wie man im Beispielszenario hoffentlich gesehen hat, bietet ein UDDI Service Broker die Möglichkeit, auf unterschiedlichste Situation dynamisch zu reagieren, Dank Komponenten,die Firmen oder Personen schon programmiert haben und uns zur Verfügung stellen.



6. Webservice-Tutorial

6.1. Webservice erstellen mit Microsoft Visual Studio 20051. Menü: DateiNeuWebsite…

2. Vorlage: ASP.NET-Webdienst, Sprache: Visual C#

3. Es wird ein Projekt-Grundgerüst generiert:

Der eigentliche Webservice Service.asmx verweist auf die Datei mit dem C#-Code Service.cs. Diese Aufteilung erhöht die Übersichtlichkeit bei großen Webservice-Projekten.

4. Bei kleinen Projekten kann der C#-Code direkt in Service.asmx geschrieben und die restlichen Dateien und Ordner gelöscht werden:

5. bzw. [F5] startet den Debug-Modus zum Testen des Webservice. Es erscheint evtl. ein Hinweis auf eine fehlende Datei Web.config. Mit [Ok] wird diese automatisch generiert, der ASP.NET Development Server gestartet und im Standardbrowser die Testseite des Webservice aufgerufen.

6.2. Webservice über Microsoft IIS bereitstellen1. Microsoft Internet Information Service steht zur Verfügung bei Windows NT Server,

Windows 2000 Server, Windows Server 2003 und eingeschränkt bei Windows 2000 Professional und Windows XP Professional. Evtl. muss er zunächst aktiviert werden über SystemsteuerungSoftwareWindows-Komponenten hinzufügen/entfernen

2. Virtuelles Verzeichnis anlegen: SystemsteuerungVerwaltungInternetinformationsdienste, in der Baumstruktur zur Standardwebseite des lokalen



Rechners navigieren: Internet Information ServiceXXX(lokaler Computer)Webseiten Standardwebseite, im Kontextmenü (Rechtsklick): NeuVirtuelles Verzeichnis…

3. Webservice (*.asmx und Web.config) an dem Ort ablegen, auf den das virtuelle Verzeichnis zeigt

6.3. Webclient erstellen mit Microsoft Visual Studio 20051. Neues Projekt erstellen, z.B.: DateiNeuProjekt…, Vorlage: Visual

C#Windows-Anwendung

2. Im Kontextmenü des Projektmappenexplorer (Rechtsklick): Webverweis hinzufügen…, URL zum Webservice eintragen und testen, dem Webverweis einen Namen geben und [Verweis hinzufügen] klicken

3. Auf den Webservice kann nun in jeder Quellcode-Datei des Projektes wie auf eine normale Klasse zugegriffen werden über <Webverweisname>.<Webservicename>



7. Webservice-Beispiel

7.1. SemesterTimeServiceEs soll ein einfacher Webservice erstellt werden, der Informationen über Beginn und Ende derVorlesungs-, Prüfungs- und Ferienzeiträume an der FH Osnabrück anbietet.

Der Service wird mit Visual Studio 2005 als "Website" in C# erstellt. Da der Code sehr kompakt ist, wird er direkt in die asmx-Datei geschrieben:

SemesterTimeService.asmx

01020304050607080910111213141516171819202122232425262728

<%@ WebService Language="C#" Class="SemesterTimeService" %>

using System;using System.Web.Services;

[WebService(Namespace = "http://www.fh-osnabrueck.de/")]public class SemesterTimeService: WebService {

DateTime[] SemesterTime = { new DateTime(2006,09,25), new DateTime(2007,01,13), new DateTime(2007,02,03), new DateTime(2007,03,05), new DateTime(2007,06,16), new DateTime(2007,07,07), new DateTime(2007,09,24), new DateTime(2008,01,12), new DateTime(2008,02,02), new DateTime(2008,03,03), new DateTime(2008,06,14), new DateTime(2008,07,05), new DateTime(2008,09,22), new DateTime(2009,01,10), new DateTime(2009,01,31) }; [WebMethod(Description="Returns the date of a specific semester event")]public DateTime GetSemesterTime(int year, bool winter, string semevent) {

int index = (year - 2006) * 6 + (winter ? 0 : 3); switch (semevent) { case "SESSION": return SemesterTime[index]; case "EXAM": return SemesterTime[index+1]; case "HOLIDAY": return SemesterTime[index+2]; default: throw new ArgumentException("Unknown semester event."); } }

}

Der Webservice wird von System.Web.Services.WebService abgeleitet (Zeilen 4und 7). Die WSDL-Beschreibung des Services, die zum größten Teil automatisch generiert wird, kann in Form von C#-Attributen (Zeilen in eckigen Klammern) ergänzt werden. So wird z.B. der Namespace des SemesterTimeService auf "http://www.fh-osnabrueck.de/" festgelegt (Zeile 6).

Die Daten, die der Service anbieten soll, sind der Übersichtlichkeit wegen in einem einfachen Array gespeichert (Zeilen 9 bis 15). Bei einem realen Webservice wäre die Anbindung an eine Datenbank sinnvoller.

Der Webservice hat die Methode GetSemesterTime(). Ihr wird eine Jahreszahl, ein boolscher Wert, der zwischen Winter- und Sommersemester unterscheidet und eine Zeichenkette, die die Art des Semester-Ereignisses angibt, übergeben. Es gibt drei Arten von Ereignissen: "SESSION" steht für den Beginn eines Vorlesungszeitraumes, "EXAM" für den Beginn eines Prüfungszeitraumes und "HOLIDAY" für den Ferienbeginn. Mit diesen Parametern wird der Index berechnet, der aus dem Array das passende Datum zu dem abgefragten Semesterereignis liefert (Zeilen 19 bis 25).

Der SemesterTimeService ist nun fertig und kann z.B. mit einem Microsoft IIS im Internet angeboten werden.



7.2. SemesterTimeClientDamit Angehörige der FH Osnabrück in einfacher Weise auf den SemesterTimeService (siehe oben) zugreifen können, soll nun ein einfacher Webclient mit einer übersichtlichen grafischen Oberfläche erstellt werden.

Der Client wird mit Visual Studio 2005 als "Windows-Anwendung" in C# erstellt. Zunächst baut man in der Entwurfsansicht die grafisch Oberfläche (Form1.cs) zusammen:

Die Oberfläche gliedert sich in einen Anfrage- und einen Antwort-Bereich. Im Anfragebereich werden Elemente platziert, mit denen man zwischen Winter- und Sommersemester umschalten, die Jahreszahl einstellen und zwischen den Ereignissen "Vorlesungsbeginn", "Prüfungsbeginn" und "Ferienbeginn" wählen kann. Im Antwortbereich wird das erfragte Datum in einem Textfeld angezeigt.

Als nächstes wird in der Code-Ansicht die Programmlogik implementiert:

Form1.cs

01020304050607080910111213141516171819202122232425262728293031323334353637

using System;using System.Collections.Generic;using System.ComponentModel;using System.Data;using System.Drawing;using System.Text;using System.Windows.Forms;

namespace SemesterTimeClient {

public partial class Form1 : Form { private localhost.SemesterTimeService timeservice;

public Form1() { InitializeComponent(); timeservice = new localhost.SemesterTimeService(); }

private void CheckWebService() { // Webservice abfragen int year = (int)(numericUpDown1.Value); // Jahr bool bwinter = (comboBox1.SelectedIndex == 0) ? true : false; // Sommer- oder Wintersemester string semevent = ""; // Art des Semester-Ereignisses if (radioButton1.Checked) { semevent = "SESSION"; } // Vorlesungsbeginn else if (radioButton2.Checked) { semevent = "EXAM"; } // Prüfungsbeginn else if (radioButton3.Checked) { semevent = "HOLIDAY"; } // Ferienbeginn try { // Anfrage senden und Antwort anzeigen textBox1.Text = timeservice.GetSemesterTime(year, bwinter, semevent).ToShortDateString(); } catch (System.Web.Services.Protocols.SoapException e) { // Fehler bei der Anfrage textBox1.Text = "FEHLER"; } } // Eventhandling

private void comboBox1_SelectedIndexChanged(object sender, EventArgs e) { CheckWebService(); } private void numericUpDown1_ValueChanged(object sender, EventArgs e) {



38394041424344454647484950

CheckWebService(); } private void radioButton1_CheckedChanged(object sender, EventArgs e) { if (radioButton1.Checked) { CheckWebService(); } } private void radioButton2_CheckedChanged(object sender, EventArgs e) { if (radioButton2.Checked) { CheckWebService(); } } private void radioButton3_CheckedChanged(object sender, EventArgs e) { if (radioButton3.Checked) { CheckWebService(); } } }}

Es wird über den Webverweis localhost auf die Klasse des Webservice SemesterTimeService zugegriffen und eine Instanz timeservice angelegt (Zeilen 12 und 16). DerWebverweis muss zuvor im Projektmappenexplorer eingerichtet worden sein (siehe Webservice-Tutorial).

In der Methode CheckWebService() werden die Werte der grafischen Elemente des Anfrage-Bereichs eingelesen (Zeilen 20 bis 25) und dann als SOAP-Anfrage an den Webservice gesendet (Zeile 27). Der Webservice antwortet mit einer SOAP-Antwort, die das erfragte Datum enthält. Dieses wird formatiert und im Antwort-Bereich der grafischen Oberfläche angezeigt (Zeile 27).

Die Anfrage an den Webservice soll bei jeder Änderung der grafischen Oberfläche von neuem angestoßen werden. Dazu werden einige Eventhandling-Methoden der grafischen Elemente überschrieben, die bei Änderungen die Methode CheckWebService()aufrufen (Zeilen 34 bis 48).

Der SemesterTimeClient ist nun fertig und kann Angehörigen der FH Osnabrück zur Verfügung gestellt werden, damit sie über das Internet auf den SemesterTimeService der FHzugreifen können.

8. Quellenangaben Literatur

o Beer, Birngruber, Mössenböck, Prähofer, Wös: Die .NET-Technologie. dpunkt.verlag

Weblinks

o http://de.wikipedia.org/

o http://wwwdvs.informatik.uni-kl.de/courses/seminar/SS2004/awenzlera.pdf

o http://www.torsten-horn.de/techdocs/soap.htm

o http://www.forksoft.de/download/WebServices.pdf

o http://www.w3schools.com/

Webservices und das .NET-Framework · PDF fileSo kann z.B. ein in C# geschriebener Webservice...

Documents

Transcript of Webservices und das .NET-Framework · PDF fileSo kann z.B. ein in C# geschriebener Webservice...