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

Kapitel 16 Web Services

Bei einer Website interagiert ein Mensch mit einer Maschine, indem er einen Browser benutzt. Bei einem Web Service interagiert eine Maschine mit einer anderen Maschine.


Galileo Computing

16.1 Wie Web Services funktionieren  downtop

Web Services lösen ein Problem, das so alt ist wie die Vernetzung von Computern: Computer A benötigt das Ergebnis einer Berechnung, kann diese Berechnung aber nicht selbst ausführen. Computer B kann diese Berechnung ausführen. Wie kann Computer A den Computer B dazu bringen, diese Berechnung auszuführen und ihm das Berechnungsergebnis mitzuteilen? Das ist die grundlegende Funktionsweise von Remote Procedure Calls. Eine Prozedur soll auf einem entfernten Rechner aufgerufen und ausgeführt werden. Der Aufrufer soll das Ergebnis erhalten.

Auf diese Frage gab es schon sehr viele Antworten. In der jüngeren Zeit gibt es beispielsweise DCOM in der Microsoft-Welt oder RMI (Remote Method Invocation) in der Java-Welt. All diese Ansätze hatten zwei Nachteile:

1. Lösungen für Remote Procedure Calls sind meistens an eine bestimmte Plattform gebunden. RMI funktioniert beispielsweise nur, wenn sowohl Computer A als auch Computer B ein Java-Programm ausführen. Diese Möglichkeit gibt es zwar. Aber es ist eine klare Einschränkung. Beim Distributed Computing findet man eher eine heterogene Landschaft von unterschiedlicher Hard- und Software vor. 2. Die meisten dieser Lösungen werden von Firewalls nicht durchgelassen. Da ein Unternehmen aber seine Firewall nicht durchlöchern wird, nur um einen Remote Procedure Call zu ermöglichen, sind die bisherigen Lösungen häufig auf die Verwendung in Intranets beschränkt.

Web Services haben diese beiden Nachteile nicht. Web Services sind für den Einsatz in einem heterogenen Umfeld maßgeschneidert. Und sie kommen problemlos durch Firewalls durch, weil sie das Standardprotokoll HTTP verwenden. Jedes Unternehmen, das eine Website betreibt, kann über diese vorhandene Infrastruktur auch Web Services anbieten und nutzen. Damit sind Web Services eine Schlüsseltechnologie für die Integration verteilter Anwendungen.

Die Technologie der Web Services baut ihrerseits auf einer Reihe von Basistechnologien auf, die kurz vorgestellt werden sollen.


Galileo Computing

16.1.1 Basistechnologie HTTP  downtop

Da ist zunächst die Basistechnologie HTTP. Über HTTP können zwei Computer miteinander kommunizieren. Computer A sagt zu Computer B: »Bitte schicke mir dieses und jenes!« Und Computer B schickt dieses und jenes oder eine Fehlermeldung, wenn es nicht möglich ist. Für diese Kommunikationsart gibt es außerdem bereits ein weltweites, gut ausgebautes Netzwerk: das World Wide Web. Fast jede Firma betreibt heute einen Webserver, der auf eine entsprechende Anfrage »dieses und jenes« liefert. Das sind heute meistens Webseiten, künftig können die Ausgaben von Web Services hinzukommen. Die Durchschlagkraft von Web Services basiert im Wesentlichen darauf, dass Web Services auf dieser existierenden HTTP-Infrastruktur aufbauen und nicht den Aufbau eines neuen Verkehrsnetzes erfordern.


Achtung   Der Unterschied zwischen einer Website und einem Web Service besteht hauptsächlich darin, wer hier etwas nutzt. Bei einer Website interagiert ein Mensch (mit Hilfe des Browsers) mit einer Maschine (dem Webserver). Beim einem Web Service interagieren zwei Maschinen.


Galileo Computing

16.1.2 Basistechnologie XML  downtop

Über HTTP werden in der Regel Daten im HTML-Format verschickt. Das muss aber nicht sein. HTTP kann Daten beliebigen Typs verschicken. Die Entwicklung von Web Services nahm in dem Moment ihren Anfang, in dem jemand ungefähr folgende Idee hatte: Warum soll ich eigentlich immer nur so Sachen wie

<p>Das ist <b>fett</b></p>

über HTTP verschicken? Könnte ich nicht auch so etwas verschicken:

<function name="verdoppeln">
<parameter value="35"></function>

Vom Format her ist das XML. Mit XML kann man seine eigenen Tags und Attribute definieren. Wenn der gegenüberliegende Server das jetzt richtig auswertet, dann könnte er doch anschließend so etwas wie

<ergebnis value="70">

zurückliefern und mein Remote Procedure Call wäre perfekt. Web Services machen im Grunde genau das. XML ist die Voraussetzung für diese Art der Kommunikation. XML hat noch kein Vokabular für Remote Procedure Calls, aber immerhin bereits ein Alphabet, das in der Computerwelt weithin akzeptiert ist.


Galileo Computing

16.1.3 Basistechnologie SOAP  downtop

Und SOAP (Simple Object Access Protocol) liefert schließlich das einheitliche Vokabular, das Remote Procedure Calls über HTTP ermöglicht. So wie HTML die Namen von Elementen und Attributen für die Gestaltung von Webseiten zur Verfügung stellt, so definiert SOAP die Elemente und Attribute, die für den Aufruf von entfernten Methoden verwendet werden. Dabei ist SOAP nicht auf einfache Schlüssel-Wert-Paare beschränkt, sondern es kann auch komplexere Objekte verwenden.


Galileo Computing

16.1.4 Umdenken beim Entwickeln von Web Services  toptop

Ein Entwickler, der Web Services entwickeln will, muss umdenken. Als Webentwickler ist man es gewöhnt, in zwei Ebenen zu denken. Da gibt es auf der einen Seite den Webserver und auf der anderen Seite den Web-Client in Gestalt eines Browsers.

Wenn Sie Web Services entwickeln, dann müssen Sie auch zweiseitig denken, aber jetzt müssen Sie sich zwei Server vorstellen. Der eine Computer hat den Service und der andere Computer will ihn benutzen. Um Web Services verstehen zu können, müssen Sie gedanklich zwei Server programmieren, nicht nur einen, und für jeden Server sind andere Arbeitsschritte nötig. Auch der Rechner, der einen Service in Anspruch nimmt, ist in der Regel selbst ein Server und zwar dann, wenn er die gewonnenen Erkenntnisse etwa in seine Website einbaut. Dann haben Sie ein dreistufiges Modell.

Die folgenden Abschnitte entsprechen diesem Aufbau. Der erste Server bietet einen Web Service an. Diesen grundlegenden Vorgang erläutert Abschnitt 16.2, Einen einfachen Web Service erstellen und anbieten. Der zweite Server konsumiert den Web Service. Abschnitt 16.3, Einen Web Service verwenden, erläutert, welche Arbeiten für die Nutzung des Services auszuführen sind.

Diese beiden Abschnitte spielen zunächst ein schlichtes »Hello, world«-Beispiel durch. Im Abschnitt 16.4, Einen Web Service mit einem SOAP-Header sichern, lernen Sie, wie Sie einen Passwortschutz für einen Web Service integrieren. Abschnitt 16.5, Ein DataSet-Objekt übertragen, zeigt, wie sie ein DataSet-Objekt über einen Web Service transportieren können. Abschnitt 16.6, Web Services finden, erläutert schließlich Möglichkeiten, Web Services gezielt aufzufinden.

  

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