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
# 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. ## 16.1 Wie Web Services funktionieren 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. ### 16.1.1 Basistechnologie HTTP 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.
### 16.1.2 Basistechnologie XML Ü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. ### 16.1.3 Basistechnologie SOAP 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. ### 16.1.4 Umdenken beim Entwickeln von Web Services 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.
<< 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