Unterabschnitte
2. Web Service Architekturen
Die W3C Working Group stellt in ihrer [3, Definition von Web Service Architekturen]
vier Modelle vor. Bis auf das service-orientierte werden die Modelle hier nur kurz angeschnitten.
Abbildung 2.1:
Das W3C Meta-Modell verschiedener Architekturen
[3, W3C Working Group Note 11 Feb 2004] |
- Das Message Oriented Model (MOM)
Hauptaugenmerk in diesem Modell liegt auf dem Verarbeiten von Nachrichten.
Eine Nachricht hat einen Sender und einen Empfänger, besitzt eine definierte
Struktur und wird auf eine bestimmte Weise übermittelt.
- Das Resource Oriented Model (ROM)
In diesem Modell werden Web Services als eine Resource verstanden. Eine
Resource hat einen Uniform Resource Identifier (URI), mit dem sie eindeutig
bestimmt ist. Eine Person oder Organisation besitzt eine Ressource.
- Das Policy Model (POM)
Policy, übersetzt ``Politik'' oder auch ``Verfahrensweise'', regelt Beziehungen
auf der Basis von ``Erlaubnissen'' (permissions). Sicherheit (security) und
Qualitätsmerkmale (qualitiy of service) werden in diesem Modell ebenfalls
gut abgebildet. Daher kann in diesem Modell Sicherheit am effizientesten
modelliert werden.
- Das Service Oriented Model (SOM)
Dieses Modell ist wohl dasjenige, dass die größte Parallele
zur realen Welt darstellt. Services werden entwickelt, um
der Welt Funktionalitäten bereitzustellen. Der Schlüssel zum Erfolg
dieses Ansatzes ist eine gute Beschreibung und Verbreitung der verfügbaren
Services. Im Folgenden wird dieser Ansatz weiterverfolgt.
2.2 Service orientierte Architektur
``SOA is about thinking of your system as independent pieces
that provided services instead of components that provide methods,
regardless of how those services are exposed. Thinking in terms of
services gives you a much better handle on what's important
in your system and what are implementation details'' - Chris Sells
Diese Zusammenfassung beschreibt in wenigen Sätzen, was man unter
einer Service orientierten Architektur versteht. Das System wird nurmehr
als Ansammlung von Teilen angesehen, die Dienste bereitstellen. Dies
löst die Sichtweise von Komponenten ab, die Methoden bereitstellen.
Web-Services sind in der Regel Client-Server Anwendungen. Die Kommunikation
geschieht service-orientiert mittels so genannter SOAP-Nachrichten,
die zumeist in HTTP-Pakete verpackt werden. Die Übertragung übernimmt in der Regel
ein TCP/IP-Netzwerk, meist das Internet. Netzwerk-seitig ist die
Kommunikation standardisiert und plattformunabhänig.
Der Client öffnet eine Verbindung, indem er einen so genannten
SOAP-Request an den Web-Service sendet. Als
Antwort erhält er dann einen SOAP-Response .
Abbildung 2.2:
Web Services auf Service-orientierter Basis
[4, SURPRISE 2002 - Web services based on XML] |
2.2.1 Rollenteilung
Eine service-orientierte Architektur sieht eine Rollenteilung vor.
Ein Server, der Service-Provier, bieten dem Service-Requestor,
z.B. einer Endanwendung oder einem weiteren Web-basierten Dienst
seine Dienste an. Der Client ruft dabei die gewünschte Funktion
des Servers auf und bekommt nach erfolgreicher Bearbeitung das
Ergebnis zurückgesand. Beispiele für einfache Web-Services sind
Wetterberichte, die nach Angabe einer Koordinate oder Ortes dann
einen Wetterbericht zurückliefern.
In der nachfolgenden Grafik ist schematisch dargestellt, wie
die drei beteiligten Instanzen miteinander interagieren.
Abbildung 2.3:
Rollenteilung
[6, An Introduction to Web Services] |
2.2.1.1 Service Requestor
Ein Service-Requestor kann eine Person, eine Anwendung oder ein Agent
sein, die bzw. der einen Service in Anspruch nehmen möchte. In der Regel
sind bei Web-Service-Architekturen die Service-Requestor Anwendungen oder
Agenten. Personen bedienen dabei die Anwendungen, welche die Services dann
in Anspruch nehmen.
Für einen Service-Requestor treten folgende Fragen auf:
- wie finde ich (als Person) den benötigten oder einen ähnlichen Dienst?
- wie findet eine Anwendung oder ein Agent einen benötigten Dienst?
- welche Informationen muss ich an den Dienst übermitteln und mit welchen
Antworten habe ich zu rechnen?
- wie muss mit der Schnittstelle des Dienstes kommuniziert werden?
Antworten auf diese Fragen: Google, UDDI, SOAP, WSDL B :-)
2.2.1.2 Service Provider
Der Service-Provider ist eine Software, die einen Web Service
zur Verfügung stellt. Die Kommunikation verläuft über SOAP-Nachrichten zwischen
den Beteiligten.
Zur Beschreibung der Schnittstelle eines Web-Services wurde WSDL entwickelt.
Dieses XML-Dokument beschreibt genau, welche Parameter der Service benötigt
und welche Rückgabewerte er liefert.
Beispiel: [27, Euro 2004 Tournament Schedule Web Service]
2.2.1.3 Service Registry
Beispiel: [26, http://www.xmethods.com]
Unter einer Service Registry versteht man einen Verzeichnisdienst,
der dem Service Requestor Informationen über Service Provider bereitstellt.
In der Regel stellt die Service Registry Such-Mechanismen zur Verfügung, die
eine automatisierte Suche nach benötigten Diensten zulassen.
Als Protokoll zur Suche nach Services wurde UDDI B zum Veröffentlichen
von Verzeichnissen entwickelt.
In der Nachfolgenden Grafik wird veranschaulicht, wie ein Web-Service
entsteht. Vom Design bis zur Benutzung des Services werden einige Schritte
durchlaufen.
Der Service Client versucht zunächst, bei einer UDDI Registry einen
geeigneten Dienst ausfindig zu machen. Danach wird ein SOAP-Client erstellt,
der mit dem aufgefundenen Dienst kommunizieren soll. Die Programmiersprache,
Plattform und das Betriebssystem, mit der dieser Client erstellt wird, spielen
dabei keine Rolle.
Um sich über die Art und Weise
der Kommunikation zu einigen, hat der Service Provider für seinen Dienst
eine Spezifikation der Schnittstelle in WSDL zur Verfügung gestellt. Durch
die Registrierung bei der UDDI Registry sind diese Informationen für den
Service Client transparent verfügbar. An dieser Stelle sind alle Vorkehrungen
zur Erschaffung einer Infrastruktur erfüllt, und der Client kann nun mit dem
Service des Providers über SOAP kommunizieren.
Abbildung 2.4:
Web Service Prozess
[4, SURPRISE 2002 - Web services based on XML] |
http://www.psitronic.de/ti/semanticweb/wsa/
|
|