» Home » Software-technologien » Web Services » Use Cases

Anwendungsszenarien von Webservices

Im Übersichtsartikel „Web Services Architecture Usage Scenarios, W3C Working Group Note 11 February 2004 “ (http://www.w3.org/TR/ws-arch-scenarios/) findet man – wie der Name schon vermuten lässt, eine Reihe von Möglichkeiten, wie Webservices genutzt werden können, wobei insbesondere keine besondere Technologie der Implementierung im Vordergrund steht. Wie bei dieser Art von W3C-Dokumenten üblich, werden typische Anwendungsfälle (Use Cases, http://www.w3.org/TR/ws-arch-scenarios/#description) identifiziert, mit einem Titel versehen und beschrieben.

Die verschiedenen Anwendungsfälle werden im Folgenden kurz vorgestellt und zusammengefasst. Sie geben bereits einen umfangreichen Überblick über die Möglichkeiten, die mit Webservices aus Programmierersicht realisiert werden können und welche Teilbereiche der Programmierung und Entwicklung es geben kann.

Die verschiedenen Szenarien sind in Gruppe unterteilt, die in dieser Form im Originaldokument nicht zu finden sind, welche aber einige typische Bereiche aufzeigen wollen, in denen sich die Anwendungsentwicklung bewegt.

Beispiel

Ein Beispiel soll die Verwendung von Webservices noch einmal konkretisieren und mit Leben füllen. Es verwendet das gängige Bild einer Reisebuchung, in dem besonders deutlich die verschiedenen Interessen der Organisationen zum Ausdruck kommen, welche die einzelnen Webservices im Beispiel unterhalten und anbieten.

Anwendungsfall 1: Konzertkarten kaufen

Ziel / Kontext	Der Benutzer möchte Konzertkarten für ein bestimmtes Konzert in einer bestimmten Stadt erwerben.
Szenario / Schritte	Der Benutzer wählt in einer Übersichtsliste mit Konzertdaten das gewünschte Konzert aus. Er erhält Informationen über zur Verfügung stehende Preis- und Platzkategorien. Er informiert sich über die Saalplanbuchung über freie Plätze in der von ihm gewählten Preiskategorie. Er wählt Plätze und damit Konzertkarten in seinen Warenkorb. Er bestätigt die Auswahl und bezahlt die Karten mit Hilfe seiner Kreditkarte.
Erweiterungen	Wenn das Konzert in einer entfernt liegenden Stadt stattfindet, kann eine Reise zusätzlich gebucht werden: Anwendungsfälle 2 und 3.
Eingeschlossene Anwendungsfälle	Im Standardszenario sind die Anwendungsfälle 4 und 5 enthalten.
Technologien / Erfordernisse	Einfache, atomare Datentypen über Musiker, die gerade auf Tour sind, können genauso zum Einsatz kommen wie komplexe XML-Strukturen mit Tourdaten und Verfügbarkeitsinformationen.

Anwendungsfall 2: Fahrt zum Konzert buchen

Ziel / Kontext	Das Konzert findet in einer entfernt liegenden Stadt statt und erfordert eine Bahnreise.
Szenario / Schritte	Der Benutzer entscheidet sich, mit der Bahn anzureisen und wünscht Informationen über mögliche Bahnverbindungen am gleichen Tag oder einen Tag vorher sowie einen Tag später. Von seinem eingegebenen Startort aus werden verschiedene Bahnverbindungen zur Konzertstadt ausgewählt, die zeitlich vor dem Konzert liegen. Er entscheidet sich für eine dieser Verbindungen. Vom Konzertort aus werden zeitlich nach dem Konzert liegende Verbindungen ausgewählt, die zu seinem Startort zurückführen. Er entscheidet sich für eine dieser Verbindungen. Er bezahlt die Bahnfahrkarten mit seiner Kreditkarte.
Eingeschlossene Anwendungsfälle	Im Standardszenario ist der Anwendungsfall 4 enthalten.
Technologien / Erfordernisse	Komplexe XML-Strukturen werden ausgetauscht.

Anwendungsfall 3: Hotel am Konzertort buchen

Ziel / Kontext	Der Benutzer hat sich für ein Konzert entschieden, das nicht in der unmittelbaren Nähe seines Heimatortes stattfindet und benötigt ein Hotel.
Szenario / Schritte	Der Benutzer wünscht Informationen über Hotels, die in unmittelbarer Nähe zum Veranstaltungsort (Konzerthalle, Stadion) liegen. Sofern für den Benutzer bereits Bahnfahrkarten gekauft wurden, werden die Daten verwendet, um Ankunft und Abreise zu bestimmen. Ansonsten muss er diese Daten erfassen bzw. sie werden standardmäßig einen Tag vor und einen Tag nach dem Konzert vorgschlagen. Der Benutzer entscheidet sich für eines der vorgeschlagenen Hotels und bucht es mit seiner Kreditkarte.
Eingeschlossene Anwendungsfälle	Im Standardszenario ist der Anwendungsfall 4 enthalten.
Technologien / Erfordernisse	Komplexe XML-Strukturen werden ausgetauscht.

Anwendungsfall 4: Sitzplatz in der Halle auswählen

Ziel / Kontext	Der Benutzer hat sich für eine Preiskategorie und einen Konzerttermin entschieden und möchte nun im Rahmen der gewählten Kategorie einen Platz auswählen.
Szenario / Schritte	Der Benutzer entscheidet sich für die Saalplanbuchung, nachdem er einen Konzerttermin und eine Preiskategorie ausgewählt hat. Die verfügbaren Plätze in seiner Preiskategorie werden angezeigt. Er markiert die für ihn interessanten Plätze, für die er Karten erwerben möchte, und entscheidet sich für den Kauf, indem er die Karten in seinen Warenkorb legt.
Erweiterungen	Keine besonderen.
Technologien / Erfordernisse	Keine besonderen.

Anwendungsfall 5: Bezahlung per Kreditkarte

Ziel / Kontext	Der Benutzer möchte Dienstleistungen oder Güter elektronisch erwerben und mit seiner Kreditkarte bezahlen.
Szenario / Schritte	Der Benutzer entscheidet sich für den Erwerb einer Dienstleistung oder eines Produkts und wählt als Bezahlungsoption seine Kreditkarte. Er gibt seine Daten wie Kreditkartenart, -nummer und –typ sowie die Prüfziffer an und bestätigt die Daten.
Erweiterungen	Keine besonderen.
Technologien / Erfordernisse	Komplexe XML-Strukturen werden ausgetauscht.

Die nächste Abbildung zeigt die verschiedenen Webservices, aus denen das beschriebene Gesamtszenario zusammengesetzt ist. Aus Platzgründen wurden die Szenarien und die verfügbaren Anwendungsfälle sehr knapp beschrieben und nicht in der für eine realistische Darstellung notwendigen Genauigkeit. Hervorzuheben ist, dass in der erweiterten Form eines Konzertkartenverkaufs verschiedene Plattformen (Hotelsuche und -buchung, Bahnfahrkartenbuchung) zusätzlich integriert werden. Dies geschieht für den Benutzer völlig transparent und scheinbar in einer einheitlichen, integrierten Weboberfläche. In Wirklichkeit greifen Softwarekomponenten als Webservice-Klienten auf Webdienste von anderen Plattformen zu, die solche Operationen wie die Saalplanbuchung, die Auswahl von Hotels und passenden Bahnverbindungen anbieten. Aufgabe der Vorverkaufsstelle ist es, bereits verfügbare Daten wie ausgewähltes Konzert (Ort, Termin) sowie evtl. auch die Adressdaten des Kunden in automatische vorgeschlagene Reiseinformationen umzusetzen. Diese sollten zwar individuell durch den Benutzer angepasst werden können, aber zunächst auf durchschnittlichen Vorgabewerten beruhen. Die Bezahlung per Kreditkarte stellt in allen Anwendungsfällen, in denen eine Buchung stattfindet, einen eingeschlossenen Anwendungsfall dar und wird jedes Mal durchlaufen.

In der Abbildung ist mit durchgezogenen, gefetteten Pfeilen der typische Ablauf in seiner einfachsten Form niedergelegt. Die gestrichelten Pfeile deuten zusätzliche Aktivitäten des Benutzers an, also gerade die Buchung einer Reise zum Konzertort. Die durchgezogenen, nicht gefetteten Linien visualisieren dann die notwendigen weiteren Anwendungsfälle und Aktivitäten, die allerdings von optionalen Aktivitäten des Benutzers abhängig sind und nicht immer ausgeführt werden müssen.

Verwendung von Webservices

Nachrichtenaustausch

Der weitaus größte Bereich denkbarer und vom W3C aufgelisteter Anwendungsfälle betrifft den Nachrichtenaustausch, den man in Formen des einfachen Versands zu einem oder mehreren Empfängern einrichten kann und der mit oder ohne Antwort bzw. Empfangsbestätigung auftreten kann.

Fire-and-forget to single receiver: Ein Sender sendet eine Nachricht einem einzigen Empfänger zu. Der Sender benötigt keine Informationen über den Sende- und Empfangsstatus. Dies kann zwar implementiert sein, wird aber nicht für die Antwort eingesetzt.

Fire-and-forget to multiple receivers

Ein Sender sendet eine unbestätigte Nachricht an mehrere Empfänger.

Request/Response

Im Rahmen eines geordneten Nachrichtenaustausches bei der Durchführung von Geschäftsaktivitäten tauschen Sender und Empfänger jeweils Nachrichten in Form eines Frage-Antwort-Schemas aus. Dabei handelt es sich nicht um eine einfache Empfangsbestätigung, sondern vielmehr um eine konstruierte Antwort nach Verarbeitung der Frage.

Remote Procedure Call (RPC)

Der Sender kann durch die Übergabe von Parametern, die in serialisierter Form übertragen werden, einen Dienst (Methode, Funktion, Prozedur) des Servers aufrufen. Die Implementierung unterscheidet sich vom Frage-Antwort-Schema in der Art des Nachrichtenaufbaus (Serialisierung von Parametern).

Multiple Faults

Eine Methode kann mehrere verschiedene Fehler auslösen, die je nach Anwendungszusammenhang unterschiedliche Inhalte haben oder Standardfehler sowie eigene Fehlertypen enthalten (ähnlich dem Werfen eigener Ausnahmen / Exceptions).

Request with acknowledgement

Der Sender benötigt für den Nachrichtenaustausch mit dem Empfänger eine verlässliche Bestätigung über den Versand / Erhalt der nachricht, sodass die beiden Statusinformationen {sicherer Versand | Fehler} rückübermittelt werden.

Conversational message exchange

Der Kommunikationsprozess zieht sich über mehrere Nachrichten hin und erfordert eine merklich längere Zeitdauer als das einfache Frage/Antwort-Schema. Dies betrifft bspw. die Einrichtung von komplexen Aushandlungs- und Verhandlungssituationen und Markplätzen.

Asynchronous messaging

Der Nachrichtenaustausch verläuft asynchron, sodass ein Sender seine Antwort zu einem beliebigen späteren Zeitpunkt erwartet, aber nicht unmittelbar für die weitere Ausführung benötigt.

Multiple asynchronous responses

Der Nachrichtenaustausch ist asynchron, wobei in diesem Fall nicht nur eine, sondern mehrere Antworten verschiedener Server als Antwort gesendet werden.

Einsatz von Unterhändlern

Die beiden Anwendungsfällen in diesem Bereich konzentrieren sich zum einen auf den mehrstufigen Nachrichtenaustausch und die Einrichtung von Maklersystemen.

Third party intermediary

Eine zentrale Anlaufstelle in Form eines Marktplatzes fungiert als Makler zwischen Anbietern und Nachfragern. Während die Käufer ihre Anfragen dem Makler stellen, sendet dieser den Anbietern die gewünschten oder für sie passenden Anfragen weiter.

Communication via multiple intermediaries

Der Nachrichtenversand wird über mehrere Stufen hinweg ausgeführt. Dabei leitet eine Zwischenstation eine eingehende Nachricht an den eigentlichen und endgültigen Emfpänger auf Anweisung des Senders weiter. Zur Nachrichtenverfolgung und -kontrolle werden Routing-Informationen aus dem Nachrichtenkopf gespeichert.

Caching

Caching-Mechanismen sollen mit Hilfe von Webdiensten eingerichtet werden.

Caching

Einrichtung und Aufrechterhaltung von Caching-Mechanismen für Zielsetzungen wie Bandbreitenausnutzung, Lastverteilung oder Zwischenspeicherung zur verbesserten Effizienz und Geschwindigkeitsoptimierung.

Caching with expiration

Einrichtung und Aufrechterhaltung von Caching-Mechanismen mit Gültigkeitsüberprüfungen und Verfallszeiten.

Nachrichtenmanagement

Die Nachrichtenübertragung und Rückverfolgung soll webdienstbasiert erfolgen.

Routing

Organisierter Nachrichtenversand und Routenkontrolle.

Tracking

Ein Dienstanbieter benötigt Kontrollinformationen, welche verarbeitenden Zwischenstufen während des Nachrichtenversands an diesem Prozess beteiligt waren.

Verschlüsselung

Nachrichtenköpfe und –daten / -anhänge sollen verschlüsselt übertragen werden.

Request with encrypted payload

Der Sender möchte die Nutzdaten seiner Nachricht verschlüsselt übertragen. Beide Anwendungen müssen sich vor dem Versand auf eine Verschlüsselungstechnik einigen.

Message header and payload encryption

Die Verschlüsselung soll sich sowohl auf den Kopf- als auch auf den Datenbereich der Nachricht erstrecken.

Attachment encryption

Die Verschlüsselung bezieht sich auf den Nachrichtenanhang.

Sicherheit

Sender, Nachrichteninhalt und ihre Struktur sollen bestätigt und überprüfbar sein.

Authentication

Der Klient eines Webservices identifziert sich mit Nutzername, Passwort etc.

Message Integrity

Beide am Austauschprozess beteiligte Parteien möchten sicher stellen, dass die Nachricht ohne Veränderung / Manipulation transportiert wurde.

Authentication of data

Die Daten selbst und nicht der Sender sollen authentifiziert werden, um die Richtigkeit der Daten zu gewährleisten.

Entdeckung und Verzeichnisdienste

Sofern Webservices öffentlich oder innerhalb einer bestimmten Umgebung zentral gespeichert werden sollen, bieten sich Verzeichnisdienste an. Sie erlauben die Suche und automatisierte Entdeckung von geeigneten Webdiensten.

Address based Discovery

Nach Angabe einer Service-Adresse erhält der Sender eine Beschreibung des Dienstes.

Registry based discovery

Menschliche Akteure oder Softwarekomponenten verwenden einen Verzeichnisdienst, um Webservices und ihre Schnittstellen / Operationen zu entdecken.

Management Capability Discovery

Ein menschlicher Akteur entdeckt einen Dienst und möchte ihn verwenden und für die Benutzung verwalten. Ob dies möglich ist, kann durch eine entsprechende unterstützende Funktion getestet werden.

Sonstiges

Transaction

Austausch von Transaktionskontexten.

Sending non-XML data

Austausch von nicht-XML-Daten (binäre Daten).

Event notification

Abonnementsystem zur Benachrichtigung bei bestimmten Ereignissen.

System Messages

Austausch von System-Nachrichten zum Service-/Nachrichtenstatus.

Service Metadata

Zusätzlicher Austausch von Metadaten für die Verwendung des Dienstes.

Service Level attributes

Ähnliche, aber nicht vollständig gleiche Dienste werden von unterschiedlichen Servern angeboten. Ein Verzeichnisdienst, der diese Dienste klassifiziert, könnte zusätzlich die Unterstützung von bestimmten Eigenschaften als Service-Level / Implementierungsvarianten einordnen und durchsuchen.

Operation Level attributes

Die unterschiedlichen Operationen eines Dienstes sollen mit Level-/Unterstützungsattributen versehen werden. Sie charakterisieren eine Operation weiter und geben die zusätzlichen Erfordernisse oder Umstände ihrer Benutzung an (wie z.B. Transaktionsunterstützung).

Classification system for operations

Die verschiedenen ähnlichen Operationen eines Dienstes werden in einem Klassifizierungssystem verzeichnet, im WSDL-Dokument beschrieben und dann dynamisch ausgewählt.

Quality of service

Ein bestimmtes Service-Level soll bei der Ausführung der Operation eingehalten werden. Dies wird in der Nachricht vermerkt.

Versioning

Versionierung von Schnittstellen / Operationen.