Architekturstile in Web-Services

Ein Web-Service kann einen RPC-Stil (Remote Procedure Call) oder einen Hybridstil namens REST-RPC darstellen. RPC ist ein dokumentorientierter Stil, der REST (Representational State Transfer) zugeordnet ist.

Web-Services erfüllen traditionell den RPC-Stil. Sie verwenden einen geschäftsspezifischen Operationsnamen (z. B. UpdateEmployeeData) und eine Gruppe von Argumenten, als ob Sie eine Funktion aufrufen würden. In vielen Fällen wird ein Rückgabewert erwartet.

Der REST-konforme Stil basiert auf der Übertragung von höchstens einer Geschäftsdateneinheit. Die Serviceimplementierung kann alle erforderlichen Aktionen ausführen, der Operationsname ist allerdings generisch. Der Operationsname kann beispielsweise GET oder UPDATE lauten.

Der REST-konforme Stil verdeckt Details. Beispielsweise könnte festgelegt werden, dass ein Mitarbeiterdatensatz nur auf eine von mehreren möglichen Arten verarbeitet wird, unabhängig vom Verwendungszweck der Daten. Ein geschäftsspezifischer Name wie UpdateEmployeeData ist nicht aussagekräftig genug, um zu bestimmen, welche Operation ausgeführt werden soll.

REST-RPC-Services verwenden geschäftsspezifische Operationsnamen. In der Regel verwenden diese Services einen RPC-Stil für den Datenaustausch, dafür aber keine komplexen Verwaltungsdateien, die zur Ausführung traditioneller Web-Services erforderlich sind.

SOAP-Services mit RPC-Stil

Bei einem traditionellen Web-Service erfolgt der Empfang und die Rückgabe von Daten im SOAP-Format. Der primäre Inhalt des HTTP-Entitätshauptteils (entity-body) ist die SOAP-Rahmenanweisung:
<Envelope>
   <Header>
      <!-- SOAP Headers here, for QoS -->
   </Header>
   <Body>
      <!-- Business data -->
   </Body>
</Envelope>

Die SOAP-Nachricht ist nicht komplex. Die Header sind der größte Vorteil von SOAP, da sie Unterstützung für Sicherheit und Servicekoordination bieten. Der Hauptteil enthält die Daten, die während einer Serviceanforderung von der Serviceimplementierung oder während einer Serviceantwort vom Anforderer verwendet werden.

Bei traditionellen Web-Services bezieht sich der Inhalt der SOAP-Rahmenanweisung auf den Inhalt der WSDL-Dateien (WSDL - Web Services Description Language), die komplex sind. Diese Dateien werden zu folgenden Zeiten verwendet:
  • Beim Service-Design, um die Serviceschnittstelle an die Entwickler und andere Designer zu kommunizieren.
  • Bei der Entwicklung des Anforderers, um den Prozess zu unterstützen, über den der Entwickler die Daten definiert, die mit dem Service ausgetauscht werden.
  • Zur Laufzeit, um die Serviceposition anzugeben und eine Gültigkeitsprüfung der SOAP-Nachricht zur Laufzeit zu ermöglichen.

Mit der konventionellen Technologie können Sie die WSDL-Datei aktualisieren, die vom Anforderer zur Laufzeit verwendet wird, um den Anforderer zum Zugriff auf den gleichnamigen Service an einer anderen Position zu veranlassen. Auf diese Weise können Sie schnell auf technische Änderungen reagieren, die beispielsweise bei einem Unternehmenszusammenschluss nötig werden.

Entwickler und Implementierer verwenden zum Arbeiten mit der WSDL-Datei automatisierte Tools.

REST-Services

In manchen Kontexten verwendet ein REST-Service Webfunktionen, um dem REST-konformen Stil zu entsprechen. Beim REST-konformen Stil wird eine einzelne Geschäftsdateneinheit übertragen (sofern vorhanden) und ein eingegrenzter Satz von Operationsnamen verwendet. Darüber hinaus enthält die Serviceadresse Informationen zu den Daten, die verarbeitet werden sollen. Betrachten wir beispielsweise die folgende Adresse, die aus drei Qualifikationsmerkmalen besteht:
www.example.com/employee/123

Die Adresse bezieht sich nicht auf eine Webseite, sondern auf Informationen zu einem Mitarbeiter (zweites Qualifikationsmerkmal). Die Adresse bezieht sich insbesondere auf Informationen zu einem Mitarbeiter mit der Nummer 123 (drittes Qualifikationsmerkmal).

Websites und REST-Services sind einer Vielzahl von Adressen zugeordnet. Bei einer Website bietet eine Adresse Zugriff auf eine Webseite. Bei einem REST-Service bietet eine Adresse Zugriff auf eine Geschäftsdateneinheit.

Ein REST-Service stellt mindestens eine der folgenden vier Operationen bereit:
  • GET: zum Lesen von Daten
  • POST: zum Erstellen von Daten
  • PUT: zum Aktualisieren von Daten
  • DELETE: zum Löschen von Daten
Diese Operationen entsprechen den wichtigsten HTTP-Methoden, die in der HTTP-Anforderungsnachricht angegeben werden können.

REST-Services beinhalten im Allgemeinen keine WSDL-Definitionen.

Wenn für einen REST-Service eine HTTP-Nachricht verwendet wird, enthält der Entitätshauptteil häufig Geschäftsdaten in Form von XML (Extensible Markup Language) oder JSON (JavaScript Object Notation). In den meisten Fällen ist keine SOAP-Rahmenanweisung vorhanden.

Einige Autoren erwarten für den Datenaustausch mit REST-Services eine häufigere Verwendung der SOAP-Rahmenanweisung oder zumindest den verstärkten Einsatz von SOAP- oder HTTP-Headern, damit die SOA-Laufzeitsoftware QoS-Probleme besser bewältigen kann.

Obwohl die Informationen in diesem Thema zwischen REST- und SOAP-Services unterscheiden, muss die eigentliche Unterscheidung zwischen dem RPC- und dem REST-konformen Stil gemacht werden. Weitere Informationen zu REST finden Sie in 'REST für Entwickler'.

Weitere Informationsquellen

Eine detaillierte Einführung in REST enthält das Buch Restful Web Services von Richardson und Ruby (O'Reilly Media, Inc., Mai 2007).

Einen Überblick über Serviceinteraktionen und einige RPC-bezogene Technologien enthält die Veröffentlichung SOA for the Business Developer von Margolis und Sharpe (MC Press, Mai 2007). Dieser Text gibt außerdem einen Überblick über die folgenden Bereiche:
  • XML (Extensible Markup Language), die Basis des mit Web-Services verwendeten SOAP-Formats; wird manchmal auch als Basis für Nachrichten verwendet wird, die mit einem REST-Service ausgetauscht werden.
  • XML-Schema, das im Grunde ein Code zur Überprüfung von XML ist.

Bemerkung

Ein Teil des oben aufgeführten Materials stammt aus Enterprise Web 2.0 with EGL (MC Press, 2009; http://www.mc-store.com/5107.html).


Feedback