Webservices und das .NET-Framework - Komponentenbasierte Softwareentwicklung - von Sebastian Ahlers & Daniel Bonk
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Komponentenbasierte Softwareentwicklung
Webservices
und das
.NET-Framework
von Sebastian Ahlers & Daniel BonkWebservices
mit .NET
1. Microsoft .NET .............................................................................................................. 3
1.1. Was ist .NET? ........................................................................................................ 3
1.2. Microsoft .NET Sprachen ...................................................................................... 3
2. Webservice ..................................................................................................................... 4
2.1. Was ist ein Webservice? ........................................................................................ 4
2.2. Architektur und Rollenverteilung........................................................................... 5
2.3. Beispiele ................................................................................................................. 5
3. SOAP.............................................................................................................................. 7
3.1. Was ist SOAP? ....................................................................................................... 7
3.2. Aufbau einer SOAP-Nachricht............................................................................... 7
3.3. SOAP Vorteile........................................................................................................ 8
3.4. SOAP Nachteile ..................................................................................................... 8
4. WSDL............................................................................................................................. 9
4.1. Was ist WSDL?...................................................................................................... 9
4.2. Beschreibungselemente.......................................................................................... 9
5. UDDI............................................................................................................................ 10
5.1. Was ist UDDI? ..................................................................................................... 10
5.2. Beispielszenario Buchhandel ............................................................................... 10
6. Webservice-Tutorial..................................................................................................... 14
6.1. Webservice erstellen mit Microsoft Visual Studio 2005 ..................................... 14
6.2. Webservice über Microsoft IIS bereitstellen........................................................ 14
6.3. Webclient erstellen mit Microsoft Visual Studio 2005........................................ 15
7. Webservice-Beispiel..................................................................................................... 16
7.1. SemesterTimeService........................................................................................... 16
7.2. SemesterTimeClient ............................................................................................. 17
8. Quellenangaben............................................................................................................ 18
Sebastian Ahlers & Daniel Bonk Seite 2Webservices
mit .NET
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
Sebastian Ahlers & Daniel Bonk Seite 3Webservices
mit .NET
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.
Sebastian Ahlers & Daniel Bonk Seite 4Webservices
mit .NET
2.2. Architektur und Rollenverteilung
Die Webservice-Architektur ist in drei Rollen eingeteilt:
zeigt auf
Beschreibung
UDDI
WSDL
Service Broker
zeigt auf
Service
beschreibt den
suche Service Service
SOAP
Service Konsument Service Anbieter
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. Beispiele
Es 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
Sebastian Ahlers & Daniel Bonk Seite 5Webservices
mit .NET
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.
Sebastian Ahlers & Daniel Bonk Seite 6Webservices
mit .NET
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 W3C
standardisiert 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-Nachricht
Eine 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:
+------------------------------------------------SOAP-Envelope--+
|Webservices
mit .NET
3.3. SOAP Vorteile
plattformunabhängig
programmiersprachenunabhängig
standardisiert
transportprotokollunabhängig
3.4. SOAP Nachteile
mehr Daten durch XML-Aufbau von SOAP
Sebastian Ahlers & Daniel Bonk Seite 8Webservices
mit .NET
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 einen
beschrieben, 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 aufgefassen
werden, 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. Beschreibungselemente
Ein WSDL-Dokument besteht aus verschiedenen Beschreibungselementen:
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
beschreibt die einzelnen SOAP-Nachrichten (Anfragen und Antworten)
und die dabei übergebenen Parameter
beschreibt alle Datentypen, die beim Datenaustausch zwischen Service-
Anbieter und Service-Konsument verwendet werden
beschreibt, wie Informationen übermittelt werden sollen (z.B. HTTP
POST, HTTP GET)
gibt die Adresse, unter der der Webservice erreichbar ist in Form einer URI an
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.
Sebastian Ahlers & Daniel Bonk Seite 9Webservices
mit .NET
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 Buchhandel
In 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.
Sebastian Ahlers & Daniel Bonk Seite 10Webservices
mit .NET
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
Service suchen
Buchhandel "Bücherliste" Verlage
UDDI
Service Broker
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.
A
Bücher
-liste B
Buchhandel Verlage
Bücher
-liste
Abbildung 5-2: Webservices aufrufen
1
Solange der Verlag eine aktuelle Liste der Bücher anbietet
Sebastian Ahlers & Daniel Bonk Seite 11Webservices
mit .NET
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.
Webservices Aufruf "Online bestellen"
A Daten:
Adresse
Telefax
Services:
Buchhandel Bücherliste
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.
Faxnummer erfragen und erhalten
B Daten:
Adresse
Telefax
Services:
Buchhandel Service suchen "Fax" Bücherliste
UDDI
Service Broker
Abbildung 5-4: Buchbestellung bei Verlag B
2
Parameter könnten z.B. Händlernummer und ISBN Nummer sein
Sebastian Ahlers & Daniel Bonk Seite 12Webservices
mit .NET
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.
Bestellfax
an Verlag B
"Fax" Service
Anbieter
Buchhandel "Fax" Service erhalten
UDDI
Service Broker
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.
Sebastian Ahlers & Daniel Bonk Seite 13Webservices
mit .NET
6. Webservice-Tutorial
6.1. Webservice erstellen mit Microsoft Visual Studio 2005
1. 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 bereitstellen
1. 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: SystemsteuerungVerwaltung
Internetinformationsdienste, in der Baumstruktur zur Standardwebseite des lokalen
Sebastian Ahlers & Daniel Bonk Seite 14Webservices
mit .NET
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 2005
1. 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
.
Sebastian Ahlers & Daniel Bonk Seite 15Webservices
mit .NET
7. Webservice-Beispiel
7.1. SemesterTimeService
Es soll ein einfacher Webservice erstellt werden, der Informationen über Beginn und Ende der
Vorlesungs-, 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
01
02
03 using System;
04 using System.Web.Services;
05
06 [WebService(Namespace = "http://www.fh-osnabrueck.de/")]
07 public class SemesterTimeService: WebService {
08
09 DateTime[] SemesterTime = {
10 new DateTime(2006,09,25), new DateTime(2007,01,13), new DateTime(2007,02,03),
11 new DateTime(2007,03,05), new DateTime(2007,06,16), new DateTime(2007,07,07),
12 new DateTime(2007,09,24), new DateTime(2008,01,12), new DateTime(2008,02,02),
13 new DateTime(2008,03,03), new DateTime(2008,06,14), new DateTime(2008,07,05),
14 new DateTime(2008,09,22), new DateTime(2009,01,10), new DateTime(2009,01,31)
15 };
16
17 [WebMethod(Description="Returns the date of a specific semester event")]
18 public DateTime GetSemesterTime(int year, bool winter, string semevent) {
19 int index = (year - 2006) * 6 + (winter ? 0 : 3);
20 switch (semevent) {
21 case "SESSION": return SemesterTime[index];
22 case "EXAM": return SemesterTime[index+1];
23 case "HOLIDAY": return SemesterTime[index+2];
24 default: throw new ArgumentException("Unknown semester event.");
25 }
26 }
27
28 }
Der Webservice wird von System.Web.Services.WebService abgeleitet (Zeilen 4
und 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.
Sebastian Ahlers & Daniel Bonk Seite 16Webservices
mit .NET
7.2. SemesterTimeClient
Damit 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
01 using System;
02 using System.Collections.Generic;
03 using System.ComponentModel;
04 using System.Data;
05 using System.Drawing;
06 using System.Text;
07 using System.Windows.Forms;
08
09 namespace SemesterTimeClient {
10
11 public partial class Form1 : Form {
12 private localhost.SemesterTimeService timeservice;
13
14 public Form1() {
15 InitializeComponent();
16 timeservice = new localhost.SemesterTimeService();
17 }
18
19 private void CheckWebService() { // Webservice abfragen
20 int year = (int)(numericUpDown1.Value); // Jahr
21 bool bwinter = (comboBox1.SelectedIndex == 0) ? true : false; // Sommer- oder Wintersemester
22 string semevent = ""; // Art des Semester-Ereignisses
23 if (radioButton1.Checked) { semevent = "SESSION"; } // Vorlesungsbeginn
24 else if (radioButton2.Checked) { semevent = "EXAM"; } // Prüfungsbeginn
25 else if (radioButton3.Checked) { semevent = "HOLIDAY"; } // Ferienbeginn
26 try { // Anfrage senden und Antwort anzeigen
27 textBox1.Text = timeservice.GetSemesterTime(year, bwinter, semevent).ToShortDateString();
28 }
29 catch (System.Web.Services.Protocols.SoapException e) { // Fehler bei der Anfrage
30 textBox1.Text = "FEHLER";
31 }
32 }
33 // Eventhandling
34 private void comboBox1_SelectedIndexChanged(object sender, EventArgs e) {
35 CheckWebService();
36 }
37 private void numericUpDown1_ValueChanged(object sender, EventArgs e) {
Sebastian Ahlers & Daniel Bonk Seite 17Webservices
mit .NET
38 CheckWebService();
39 }
40 private void radioButton1_CheckedChanged(object sender, EventArgs e) {
41 if (radioButton1.Checked) { CheckWebService(); }
42 }
43 private void radioButton2_CheckedChanged(object sender, EventArgs e) {
44 if (radioButton2.Checked) { CheckWebService(); }
45 }
46 private void radioButton3_CheckedChanged(object sender, EventArgs e) {
47 if (radioButton3.Checked) { CheckWebService(); }
48 }
49 }
50 }
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 FH
zugreifen 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/
Sebastian Ahlers & Daniel Bonk Seite 18Sie können auch lesen
