Inhalt
Vorwort
1 Wie .NET und ASP.NET funktionieren
2 Installation
3 Hinweise zu VB.NET
4 »Hallo, Welt!« – Ein ASP.NET-Crashkurs
5 Die Page-Klasse
6 HTML-Serversteuerelemente
7 Validierung von Anwendereingaben
8 Webserversteuerelemente
9 Webserversteuerelemente für die Darstellung von Listen
10 Webserversteuerelemente selbst erstellen
11 Der Status von Seiten, Sitzungen und Applikationen
12 ASP.NET und Datenbanken
13 »Wer darf was?« ASP.NET und Sicherheit
14 Webanwendungen erstellen und konfigurieren
15 Leistungssteigerung durch Caching
16 Web Services
A Anhang
Index
Download (ca 14,3 MB)
Buch bestellen (29,90 EUR)
Ihre Meinung?@
<< zurück | Galileo Computing / <openbook> / Einstieg in ASP.NET | vor >>
Einstieg in ASP.NET von Matthias Lohrer
| Kapitel 16 Web Services
|  | 16.1 Wie Web Services funktionieren
|  |  | 16.1.1 Basistechnologie HTTP
|  |  | 16.1.2 Basistechnologie XML
|  |  | 16.1.3 Basistechnologie SOAP
|  |  | 16.1.4 Umdenken beim Entwickeln von Web Services
|  | 16.2 Einen einfachen Web Service erstellen und anbieten
|  |  | 16.2.1 Die Datei webservice01.asmx erstellen
|  |  | 16.2.2 webservice01.asmx im Browser aufrufen
|  | 16.3 Einen Web Service verwenden
|  |  | 16.3.1 Eine Proxyklasse erstellen
|  | 16.4 Einen Web Service mit einem SOAP-Header sichern
|  |  | 16.4.1 Einen passwortgeschützten Web Service erstellen
|  |  | 16.4.2 Die Proxyklasse erzeugen
|  |  | 16.4.3 Den passwortgeschützten Web Service aufrufen
|  |  | 16.4.4 Fazit: Web Services und Sicherheit
|  | 16.5 Ein DataSet-Objekt übertragen
|  |  | 16.5.1 Den Web Service in einer asmx-Datei erstellen
|  |  | 16.5.2 Die Proxyklasse erzeugen
|  | 16.6 Web Services finden
|  |  | 16.6.1 Discovery
|  |  | 16.6.2 UDDI
|  | 16.7 Zusammenfassung und Ausblick
|  |  | 16.7.1 Zusammenfassung
|  |  | 16.7.2 Ausblick
|  |  | 16.7.3 Ressourcen
## 16.6 Web Services finden ### 16.6.1 Discovery Discovery bezeichnet den Prozess, mit dem ein Web-Service-Client Informationen über die angebotenen Web Services ermittelt. Dieser Prozess findet in der Regel während der Entwurfszeit für den Web-Service-Client statt, das heißt, der Entwickler des Web-Service-Clients stößt diesen Prozess an. Mit Hilfe einer Analogie lässt sich der Discovery-Prozess leicht nachvollziehen. Angenommen, jemand sucht im Internet Informationen zu den Produkten einer bestimmten Firma. Er weiß, wie die Firma heißt, und gibt also auf gut Glück im Browser www.firmenname.de ein. Tatsächlich erscheint die Website dieses Unternehmens. Mit Hilfe der angebotenen Navigationsmöglichkeiten kann der Interessent sich nun über die Firma und ihre Produkte informieren. Ganz besonders interessant findet er schließlich das Produkt xyz, zu dem die Seite www.firmenname.de/bereich1/sparte2/produktxyz.htm alle Informationen bietet. Zu diesem speziellen URL setzt sich der Interessent im Browser ein Lesezeichen, um die Seite gelegentlich wieder aufrufen zu können. Was ist hier passiert? Der Interessent hatte zunächst nur eine vage Vorstellung davon, wo er die gesuchten Informationen finden könnte. Durch den Besuch der Website des Unternehmens konnte er schließlich die gewünschten Informationen genau auf der Seite www.firmenname.de/bereich1/sparte2/produktxyz.htm finden. Diesen speziellen URL kannte er am Beginn seiner Suche noch nicht. Er hat ihn erst durch die Recherche entdeckt. Einen entsprechenden Vorgang gibt es auch für Web Services. Mit Hilfe des Discovery-Prozesses kann dieser Recherchevorgang für Web Services automatisiert werden. Der Discovery-Prozess erfordert auf beiden Seiten bestimmte Schritte. Der Web-Service-Anbieter erstellt ein Discovery-Dokument und der Web-Service-Konsument wertet dieses Discovery-Dokument mit Hilfe bestimmter Tools aus. #### Der Web-Service-Anbieter erstellt ein Discovery-Dokument Als Anbieter von Web Services erstellen Sie für die von Ihnen angebotenen Web Services ein oder mehrere Discovery-Dokumente in Form von XML-Dateien. Ein Discovery-Dokument beschreibt einen Web Service oder mehrere Web Services. Das Wurzelelement eines Discovery-Dokuments lautet discovery. Ein Discovery-Dokument enthält Links zu anderen Discovery-Dokumenten, XSD-Schemas und Web-Service-Beschreibungen, indem es die XML-Elemente discoveryRef, schemaRef und contractRef jeweils mit dem Attribut ref verwendet. Die einfachste Möglichkeit, für einen einzelnen Web Service eine Discovery-Datei zu erstellen, besteht darin, im Browser den Web Service mit dem Zusatz ?DISCO aufzurufen. Abbildung 16.15 zeigt beispielhaft das Resultat eines solchen Aufrufs. Hier klicken, um das Bild zu Vergrößern Abbildung 16.8 Ein Web Service kann eine Discovery-Datei für sich selbst generieren. Diese generierte XML-Datei könnten Sie als Discovery-Datei für diesen Web Service speichern. Beispielhaft soll nun in der Datei myWebservices.disco eine Discovery-Datei für die beiden Hallo-Web-Services erstellt werden. Folgende Form ist möglich:
    <?xml version="1.0"?>
    <!-- myWebservices.disco -->
    <discovery xmlns="http://schemas.xmlsoap.org/disco/">
       <contractRef ref="webservice01.asmx?WSDL"
           docRef ="webservice01.asmx"
           xmlns="http://schemas.xmlsoap.org/disco/scl/" />
       <contractRef ref="webservice02.asmx?WSDL"
           docRef ="webservice01.asmx"
           xmlns="http://schemas.xmlsoap.org/disco/scl/" />
    </discovery>
Für beide Web Services wird das Element contractRef definiert. Das Attribut ref verweist auf die Quelle für die Web-Service-Beschreibung im WSDL-Format. Das ist hier jeweils der Name des Services mit angehängtem ?WSDL. Das Attribut docRef verweist auf die Dokumentation. Eine Dokumentation eines Web Services erstellt ASP.NET automatisch, wenn die jeweilige asmx-Datei im Browser aufgerufen wird, so dass hier lediglich der Name des Web Services angegeben werden muss. Das Attribut xmlns definiert den verwendeten Namensraum. Bei den Referenzen sind sowohl relative Verweise als auch komplette Angaben mit http:// ... möglich. Im Beispiel liegt die Datei myWebservices.disco im gleichen Verzeichnis wie die Web-Service-Dateien, so dass keine weiteren Pfadangaben nötig sind. Um die Analogie zum manuellen Suchprozess auf einer Website zu komplettieren, ist noch die Frage offen, wie ein Entwickler diese Datei myWebservices.disco finden kann. Am einfachsten wäre es, wenn der Entwickler, der diese Web Services nutzen möchte, die Discovery-Datei durch die Eingabe des URL der Website finden könnte, ohne genau wissen zu müssen, welchen Namen diese Discovery-Datei trägt.
Tipp Das lässt sich über einen entsprechenden Eintrag in der Datei index.htm erreichen, beziehungsweise in derjenigen Datei, die als Default-Datei definiert ist, wenn der URL der Website ohne Angabe einer Datei aufgerufen wird.
Fügen Sie in der Startdatei, z. B. in index.htm, folgenden Eintrag hinzu:
    <head>
    <link type='text/xml'
          rel='alternate'
          href='Listings/myWebservices.disco'/>
    </head>
Mit diesem Eintrag kann ein Entwickler die Web Services, die auf Ihrer Website angeboten werden, erschließen, ohne die genauen Namen der einzelnen Web Services oder der Discovery-Datei selbst kennen zu müssen. Der folgende Abschnitt erläutert, wie der Entwickler des Web-Service-Nutzers vorgeht. #### Der Web-Service-Konsument wertet ein Discovery-Dokument aus Ein Entwickler hat davon gehört, dass die Firma xyz Web Services anbietet. Welche sind das? Hierfür enthält das .NET SDK das Tool disco.exe. Wenn die anbietende Firma so vorgegangen ist wie oben angegeben, dann reicht folgender Weg aus: Der Entwickler gibt folgendes Kommando ein: disco http://www.firmenname.de Auf Ihrem lokalen Rechner wäre das beispielsweise: disco http://localhost/ASPdotNETBuch Abbildung 16.9 zeigt die Meldungen nach dem Aufruf dieses Befehls. Hier klicken, um das Bild zu Vergrößern Abbildung 16.9 disco.exe wertet Discovery-Dateien von Web-Service-Anbietern aus. Das Tool disco.exe entdeckt im Header von index.htm den Link zur Datei 'Listings/myWebservices.disco' und wertet diese Datei aus. Das Tool speichert die Datei myWebservices.disco lokal ab. Außerdem speichert es die Web-Service-Beschreibungen für die beiden Web Services im WSDL-Format ab. Die Datei results.discomap enthält eine Übersicht über die ausgewerteten Dateien im XML-Format. Damit hat der Entwickler alle Informationen zusammen, die er benötigt, um die erforderliche Proxyklasse für die Web Services erstellen zu können, und der Discovery-Prozess ist abgeschlossen. Tabelle 16.2 verzeichnet die Optionen von disco.exe.
disco [Optionen] URL
/d oder /domain:<Domäne> | Der Domänenname für die Verbindung mit einem Proxyserver, für den eine Authentifizierung erforderlich ist
/nosave | Speichert die ermittelten Dokumente oder Ergebnisse (wsdl-, xsd-, disco- und discomap-Dateien) nicht auf der Festplatte. Standardmäßig werden diese Dokumente gespeichert.
/nologo | Unterdrückt das Startbanner
/o oder /out:<Verzeichnisname> | Das Verzeichnis, in dem die ermittelten Dokumente gespeichert werden sollen. Default: das aktuelle Verzeichnis
/p oder /password:<Passwort> | Passwort für die Verbindung mit einem Proxyserver mit erforderlicher Authentifizierung
/proxy:<URL> | Der URL des zu verwendenden Proxyservers, wenn er von den Proxy-Einstellungen des Systems abweichen sollte
/pd: oder /proxydomain:<Domäne> | Domäne für die Verbindung mit einem Proxyserver
/proxypassword: oder /pp:<Passwort> | Passwort für die Verbindung mit einem Proxyserver
/proxyusername: oder /pu: oder /u: oder /username:<Username> | Benutzername für den Proxyserver
/? | Zeigt eine Befehlsübersicht an
Tabelle 16.2 Optionen von disco.exe ### 16.6.2 UDDI Voraussetzung für die Verwendung des Tools disco.exe ist, dass jemand bereits weiß, auf welcher Website er die gesuchten Web Services finden kann. Was aber ist, wenn jemand nicht weiß, welche Website den gewünschten Service anbietet? An diesem Punkt setzt das UDDI-Projekt an. UDDI steht für Universal Description Discovery and Integration. Das Projekt ist von den Unternehmen IBM, Microsoft und Ariba initiiert worden und wird mittlerweile von zahlreichen weiteren Firmen unterstützt, darunter beispielsweise Accenture, AOL, Cisco, Dell, GE, i2, Intel, SAP und Sun. UDDI bietet eine Architektur für die Integration unterschiedlicher Web Services. Ein Unternehmen kann die von ihm angebotenen Web Services mit Hilfe von UDDI auf eine standardisierte Art und Weise formal beschreiben und auf einem UDDI-Server registrieren. Auf diese Weise haben andere Unternehmen die Möglichkeit, diese Web Services zu finden und zu nutzen. Hinter UDDI steht letztlich die Vision, digitales Business weitgehend zu automatisieren. Ein kurzes Beispiel soll zur Illustration genügen. Angenommen, ein Unternehmen versendet seine Produkte auf dem Schiffsweg und sucht eine entsprechende Frachtversicherung. Wenn die verwendete Software automatisch »UDDI beherrscht«, könnte die Software über einen UDDI-Server selbstständig nach den passenden Anbietern suchen, diese nach den entsprechenden Konditionen befragen und den Versicherungsvertrag mit dem günstigsten Anbieter selbstständig abschließen. Das ist momentan noch Zukunftsmusik, aber die Infrastruktur für solche Szenarien ist letztlich bereits vorhanden.
<< zurück | <top> | vor >>
Zum Katalog
Einstieg in ASP.NET bestellen
Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen? Ihre Meinung

.NET-Bibliothek
| Einstieg in VB.NET
| VB.NET
| Einstieg in C#
| Visual C#
| VB.NET und Datenbanken

Empfehlung
| Einstieg in XML

Shopping
Versandkostenfrei bestellen in Deutschland und Österreich Info

MyGalileo
Der Service für registrierte Leser: Info

Copyright © Galileo Press GmbH 2003
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.

[Galileo Computing]
Galileo Press GmbH, Gartenstraße 24, 53229 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, info@galileo-press.de