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.

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.

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.