eMail
 Suche
 Impressum

Unterabschnitte


2. Web Service Architekturen

2.1 Modelle

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

Image meta [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
Image websrv [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
Image wsa [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:
  1. wie finde ich (als Person) den benötigten oder einen ähnlichen Dienst?
  2. wie findet eine Anwendung oder ein Agent einen benötigten Dienst?
  3. welche Informationen muss ich an den Dienst übermitteln und mit welchen Antworten habe ich zu rechnen?
  4. 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.

2.3 Prozess eines Web-Services

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
Image wsproc [4, SURPRISE 2002 - Web services based on XML]

http://www.psitronic.de/ti/semanticweb/wsa/
Menü

Home
Funstuff
Linux
Hardware
Distributionen
Spiele
Kontakt
Projekte
Java
Webcut
Strength and Honor
A-Mobile
Holy-Wars 2
Holy-Wars 3
-> Dokumentation
Biometrie
Performanzermittlung
Mmpg
Mmpg-peer to peer
Javadoc
Mmpgp2p-Server
-> Semantic Web
-> WSA



- Impressum -
designed using WebCut - Copyright (c) 2001-2008 by Markus Sinner