Galileo Computing < openbook >
Galileo Computing - Programming the Net
Galileo Computing - Programming the Net


Einstieg in ASP.NET von Matthias Lohrer
Einstieg in ASP.NET
gp Kapitel 16 Web Services
  gp 16.1 Wie Web Services funktionieren
    gp 16.1.1 Basistechnologie HTTP
    gp 16.1.2 Basistechnologie XML
    gp 16.1.3 Basistechnologie SOAP
    gp 16.1.4 Umdenken beim Entwickeln von Web Services
  gp 16.2 Einen einfachen Web Service erstellen und anbieten
    gp 16.2.1 Die Datei webservice01.asmx erstellen
    gp 16.2.2 webservice01.asmx im Browser aufrufen
  gp 16.3 Einen Web Service verwenden
    gp 16.3.1 Eine Proxyklasse erstellen
  gp 16.4 Einen Web Service mit einem SOAP-Header sichern
    gp 16.4.1 Einen passwortgeschützten Web Service erstellen
    gp 16.4.2 Die Proxyklasse erzeugen
    gp 16.4.3 Den passwortgeschützten Web Service aufrufen
    gp 16.4.4 Fazit: Web Services und Sicherheit
  gp 16.5 Ein DataSet-Objekt übertragen
    gp 16.5.1 Den Web Service in einer asmx-Datei erstellen
    gp 16.5.2 Die Proxyklasse erzeugen
  gp 16.6 Web Services finden
    gp 16.6.1 Discovery
    gp 16.6.2 UDDI
  gp 16.7 Zusammenfassung und Ausblick
    gp 16.7.1 Zusammenfassung
    gp 16.7.2 Ausblick
    gp 16.7.3 Ressourcen


Galileo Computing

16.6 Web Services finden  downtop


Galileo Computing

16.6.1 Discovery  downtop

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.

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

Abbildung
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


Galileo Computing

16.6.2 UDDI  toptop

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.

  

Einstieg in VB.NET

VB.NET

Einstieg in C#

Visual C#

VB.NET und Datenbanken

Einstieg in XML




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