Geschrieben von: Christoph Wille
Kategorie: Web Services
This printed page brought to you by AlphaSierraPapa
Das Simple Object Access Protocol (SOAP) ist als Protokoll für Web Services schon seit langer Zeit in aller Munde, allerdings fehlte bis jetzt unter IIS eine einfache Entwicklungsplattform, um Web Services zu programmieren. Diese haben wir nun mit ASP.NET in der Hand, und ich werde Ihnen heute zeigen, wie leicht man Web Services in C# als auch VB.NET entwickeln kann.
Der heutige Artikel ist keine Theorieveranstaltung, sondern alles Hands-on. Wir benutzen SOAP, ohne uns näher damit zu beschäftigen - genau das ist das Schöne, wenn .NET ins Spiel kommt: die ganze lästige Implementierung der Infrastruktur ist bereits erledigt, man muß nur noch die eigene Funktionalität programmieren - die, für die man Geld bekommt. Die Theorie kann man getrost vergessen.
Um den heute vorgestellten Code ausführen zu können, muß ASP.NET am Server installiert sein. Für das Erstellen von Assemblies benötigt man das vollständige .NET SDK (nicht notwendigerweise am Server, allerdings auf der Maschine, auf der die Assembly kompiliert werden soll).
Die durchgängige Aufgabenstellung über alle heute vorgestellten Web Service Beispiele ist folgende: man programmiere einen Web Service, der einen Namen als String Parameter annimmt, und mit diesem eine "Hello World" Meldung erstellt, und an den Aufrufer zurückliefert. Die erste Programmiersprache, die sich dieser Herausforderung stellen muß, ist C#.
Hier ist mein Lösungsvorschlag (SampleCSService.asmx):
<%@ WebService Language="C#" Class="DemoCSService" %> using System; using System.Web.Services; public class DemoCSService : WebService { [WebMethod] public string SayHello(string strName) { return "Hello " + strName + " from C#"; } }
Die erste Zeile sieht bekannt aus - statt @Page steht bei einem Web Service die @WebService Direktive, das Language Attribut ist ident. Neu dazugekommen ist das Class Attribut. Dieses gibt an, welche der in dieser ASMX Datei definierten Klassen (ja, es können mehrere sein: die Serviceklasse und mehrere Hilfsklassen) als Web Service angesprochen werden kann. Da ich nur eine habe, ist die Wahl leicht. Die gewählte Klasse muß von WebService abgeleitet werden, und diese wiederum findet sich im eingebundenen Namespace System.Web.Services.
Die Klassenimplementierung selbst ist kaum unterschiedlich zu der anderer Klassen, der einzige Unterschied ist, daß Methoden, die durch den Service verfügbar sein sollen (=von außen aufrufbar) mit dem WebMethod Attribut markiert werden müssen. Das ist alles, und schon hat man einen funktionierenden Web Service.
Wie kann ich beweisen, daß er funktioniert? Nun, ASP.NET generiert für jeden Web Service Standardseiten, die es erlauben, die Definition des Services einzusehen (WSDL), als auch die freigegebenen Methoden aufzurufen. Alles, was man tun muß, ist den URL des Services im Internet Explorer einzutippen:
Man erhält eine Beschreibung des Services, als auch eine Liste der aufrufbaren Methoden - in unserem Fall nur SayHello. Wenn man auf die Methode klickt, bekommt man ein Formular, in dem man Parameter eintippen und die Methode aufrufen kann:
Nach Klicken des Invoke Buttons wird die Methode aufgerufen, und das Resultat in einem XML Paket zurückgeliefert:
Daß dies keine tolle benutzerfreundliche Lösung ist um Web Services zu konsumieren, ist klar aber dennoch eine andere Geschichte. Heute befassen wir uns nur mit der Erstellung eines einfachen Web Services!
In C# hätten wir die Aufgabe des Erstellens eines Web Services schon gemeistert. Nun versuchen wir unser Glück in Visual Basic.NET. Ich habe den Service SampleVBService.asmx durch einfaches Umschreiben des C# Codes erstellt, und wie man sieht, sind die notwendigen Anpassungen nicht schlimm:
<%@ WebService Language="VB" Class="DemoVBService" %> Imports System Imports System.Web.Services Public Class DemoVBService : Inherits WebService <WebMethod()> Public Function SayHello(strName As System.String) As System.String SayHello = "Hello " & strName & " from VB" End Function End Class
Im Prinzip sind die Unterschiede nur Syntax: Imports statt Using, das WebMethod in spitzen statt eckigen Klammern und eben die übliche VB Syntax für Klassen und Methoden. Auf alle Fälle ist es keineswegs schwieriger in VB.NET einen Web Service zu erstellen als in C#!
Es gilt übrigens die gleiche Vorgehensweise für das Testen: URL eintippen, und mit den vorgenerierten Seiten von ASP.NET herumspielen.
Die folgende einzeilige Datei AssemblyService.asmx erfüllt die Aufgabe auch:
<%@ WebService Class="AspHeute.SampleService" %>
Aber wie? Nun, der Name der Datei verrät mich ja sowieso: die Web Service Klasse ist in einer separaten Assembly implementiert, die kompiliert im bin Verzeichnis der Applikation liegt, und somit automatisch eingebunden wird. Ich muß nur angeben, welche von WebService abgeleitete Klasse aufgerufen werden soll.
Was sind die Vorteile, warum würde man das machen? Nun, ein gewichtiger Vorteil ist, daß Assemblies kompiliert sind, und nicht als Quelltext vorliegen. Das beschleunigt den Erstaufruf, und hindert unerfahrene Kunden daran, den Web Service nach eigenem Gutdünken zu verschlimmbessern. Also doch einige Argumente dafür, wohl aber auch dieses: der Aufwand ist nahe Null.
Warum? Nun, man muß nur den existierenden Sourcecode minus der ersten Zeile nehmen, und in eine .cs Datei verfrachten (AssemblyService.cs):
using System; using System.Web.Services; namespace AspHeute { public class SampleService : WebService { [WebMethod] public string SayHello(string strName) { return "Hello " + strName + " from the assembly"; } } }
Das Kompilieren übernimmt ein Tool wie SharpDevelop:
Zusammen mit dem Umkopieren in das bin Verzeichnis habe ich drei Minuten gebraucht - und es liegt kein Sourcecode mehr herum, der absichtlich oder unabsichtlich verändert werden könnte. Ein annehmbarer Aufwand, zumal er meist sowieso erst zum Abschluß des Projektes fällig wird.
Apropos - es ist jeder herzlich eingeladen, auch diesen dritten Service auszuprobieren!
Die heute vorgestellten Web Services waren simpel - allerdings werden auch aufwendigere Aufgabenstellungen kaum komplizierter - die Infrastruktur ist da, und sie ist sehr gut implementiert. Spätere Artikel werden zeigen, wie man nützlichere Services schreiben kann, und wie man diese dann konsumiert.
This printed page brought to you by AlphaSierraPapa
Klicken Sie hier, um den Download zu starten.
http://www.aspheute.com/code/20010621.zip
A Brief History of C#
http:/www.aspheute.com/artikel/20000713.htm
Authentifizierung in Web Services - Windows Integrated
http:/www.aspheute.com/artikel/20030429.htm
Datentypen in C#
http:/www.aspheute.com/artikel/20000726.htm
Die String Klasse in C#
http:/www.aspheute.com/artikel/20000803.htm
Einstellungssache - Applikationsdaten in web.config
http:/www.aspheute.com/artikel/20011122.htm
Index Server Abfragen per Web Service
http:/www.aspheute.com/artikel/20021107.htm
Last but not least - .NET 1.0 ist da!
http:/www.aspheute.com/artikel/20020117.htm
Session State in ASP.NET Web Services
http:/www.aspheute.com/artikel/20010627.htm
Unions in C#
http:/www.aspheute.com/artikel/20020207.htm
Web Projekte mit SharpDevelop erstellen
http:/www.aspheute.com/artikel/20010208.htm
Web Services in Anwendungen konsumieren
http:/www.aspheute.com/artikel/20010622.htm
Web Services mit dem SOAP Toolkit erstellen
http:/www.aspheute.com/artikel/20010629.htm
DotNetGerman Diskussionslisten
http://www.dotnetgerman.com/
SharpDevelop
http://www.icsharpcode.net/opensource/sd/
©2000-2006 AspHeute.com
Alle Rechte vorbehalten. Der Inhalt dieser Seiten ist urheberrechtlich geschützt.
Eine Übernahme von Texten (auch nur auszugsweise) oder Graphiken bedarf unserer schriftlichen Zustimmung.