SOA, HTTP, SOAP und REST

Gerade im Zeitalter von Internet und mobilen Anwendungen (Stichwort: Smartphone) sind verteilte Systeme/Anwendungen immer weiter auf dem Vormarsch. Sei es in der Kommunikation zwischen Personen oder zwischen unternehmensinternen und –externen Applikationen zur Automatisierung von Abläufen/Geschäftsprozessen. Bei der Umsetzung solcher Anwendungen gilt es verschiedene Protokolle und Formate in Einklang zu bringen. Auch Aspekte wie Sicherheit, Verarbeitung von Transaktionen oder Datenverluste trotz Kommunikationsproblemen zu vermeiden sind zu beachten. Gerade in diesem Zusammenhang liest man nun immer wieder Begriffe wie SOA, HTTP, SOAP, REST, usw. Ich möchte in diesem Beitrag nun auf die einzelnen Begrifflichkeiten eingehen und einige Zusammenhänge erläutern.

SOA – Service Oriented Architecture (Dienst- / Serviceorientierte Architektur)

SOA ist ein Architekturmuster oder Paradigma (Denkmuster) der Informationstechnik aus dem Bereich der verteilten Systeme, um Dienste von IT-Systemen zu strukturieren und zu nutzen. Eine besondere Rolle spielt dabei die Orientierung an Geschäftsprozessen, deren Abstraktionsebenen die Grundlage für konkrete Serviceimplementierungen sind. Es gibt keine harten Kriterien, anhand derer exakt beurteilt werden kann, ob eine Architektur oder ein System dem SOA-Architekturstil entspricht. Daher gibt es auch keine allgemein akzeptierte Definition von SOA. Zentrales Thema aller Definitionen sind die Dienste/Services und als wichtige Aspekte bzw. Vorteile des SOA-Ansatzes werden meistens genannt:

  • Auf Services basierendes Unternehmens- und IT-Architekturkonzept
  • Agil änderbare Geschäftsprozesse durch einfach und flexibel verknüpfbare Services/Dienste
  • Besser strukturierte, besser dokumentierte und an Geschäftsprozessen orientierte IT-Services
  • Besseres Verständnis und höhere Transparenz der Geschäftsprozesse
  • Autarke, lose koppelbare und austauschbare Services
  • Unterschiedliche Technologien (und Programmiersprachen) können gekoppelt werden
  • Geringeres Risiko bei Änderungen, weil Nebenwirkungen überschaubar

Jetzt wird im SOA-Umfeld oft von Services gesprochen, doch was genau ist ein Service? Services orientieren sich aus betriebwirtschaftlicher Sicht stark an den Geschäftsprozessen des Unternehmens. In SOA übernehmen Services in hohem Maße die Rolle der klassischen „Anwendung“: Unternehmen planen, entwerfen, entwickeln, testen und betreiben Services, nicht Anwendungen. Im SOA-Umfeld sind mit Services also Software-Komponenten (Sammlung von Operationen) gemeint, die zu einem Geschäftsprozess kombiniert werden können. Die Service-Komponenten (Funktionsbausteine, Module, Anwendungen) werden über öffentliche Schnittstellen (Interfaces) zur Verfügung gestellt und werden dann von einem Client über das Netzwerk konsumiert. Anders als Bibliotheken oder andere Komponenten werden Services von den Nutzern lediglich aufgerufen, aber nicht in das aufrufende System eingebettet. Ein Service definiert sich im Normalfall über folgende Eigenschaften:

  • wohldefinierte, in sich abgeschlossene fachliche Funktion
  • klar definierte veröffentlichte Schnittstelle (Vertrag). Für die Nutzung reicht es, die Schnittstelle zu kennen. Kenntnisse über die Details der Implementierung sind hingegen nicht erforderlich (Schnittstellenschicht verbirgt Implementierung und komplexe Details der Kommunikation)
  • ein Service ist plattformunabhängig, d. h. Anbieter und Nutzer eines Services können in unterschiedlichen Programmiersprachen auf verschiedenen Plattformen realisiert sein
  • Softwarekomponenten können durch Services lose gekoppelt miteinander interagieren
  • ein Service sollte grobgranular sein, um die Abhängigkeit zwischen verteilten Systemen zu senken
  • zustandslos (wenn möglich, sollten sich die Services keine Kontext- oder Sessiondaten merken)
  • Konsistenz (Operationen hinterlassen Geschäftsobjekte in einem konsistenten Zustand)
  • Schichtenarchitektur – die einzelnen Services sind hierarchisch in Schichten strukturiert, Services aus oberen Schichten können nur auf Services von unteren Schichten zugreifen, nicht umgekehrt (Strikt-Layering-Prinzip)

Was SOA nicht ist:

  • SOA ist keine Lösung für fachliche Probleme – Als Architekturparadigma gibt SOA keine Empfehlung zur Behandlung von fachlichen Problemen
  • SOA ist individuell – Es gibt keine „Standard-SOA“. Ein Unternehmen muss eine SOA immer auf die eigenen Bedürfnisse zuschneiden
  • SOA ist nicht Webservices – SOA beschreibt losgelöst von konkreten Implementierungsmethoden und -techniken ein Architekturparadigma

Einige Beispiele für Services:

  • Eröffnen eines Kontos, Abfragen des Kontostandes
  • Suche nach Flügen, Buchung eines Fluges

Serviceorientierte Architekturen helfen bei der Unterstützung von Geschäftsprozessen. Einzelne Schritte des Geschäftsprozesses werden dabei von Services, die von verschiedenen Systemen angeboten werden, realisiert. Dieses Services können innerhalb der eigenen Organisation zur Verfügung stehen oder von Geschäftspartnern angeboten werden. Angenommen man hat den folgenden Geschäftsprozess „Bestellung“, der in die folgenden Services aufgeteilt werden kann:

Geschaeftsprozess_Bestellung

Für jeden Geschäftsprozessschritt gibt es einen Service/Dienst (im oben gezeigten Schaubild z.B. Erfassung, Verfügbarkeitsprüfung, usw.). Die Implementierung – Programmiersprache, Systemvoraussetzungen usw. – der einzelnen Prozessschritte kann unterschiedlich sein. Es wäre auch denkbar, dass die Services auf unterschiedlichen Systemen oder sogar in unterschiedlichen Unternehmen implementiert sein können. So könnte die Bonitätsprüfung/Zahlungsfähigkeit des Kunden von einem Finanzdienstleister ermittelt werden. Wichtig ist jedoch, dass beispielsweise die Bonitätsprüfung immer dieselbe ist, auch wenn sie von unterschiedlichsten Prozessen oder sogar Firmen genutzt wird. Entscheidet sich das Unternehmen, die Bonitätsprüfung in andere Hände zu legen, so muss die Infrastruktur diesen Dienst nur bei einem anderen Anbieter aufrufen. Sonst ändert sich nichts weiter.

Service-Komposition / Service-Choreographie

Eine Herausforderung ist die Kapselung und Koordination von vorhandenen EDV-Komponenten wie Datenbanken, Server und Websites, so dass ihre Leistungen zu höheren Diensten zusammengefasst werden können. Durch Zusammensetzen („Orchestrierung“) von Services niedriger Abstraktionsebenen können so recht flexibel und unter Ermöglichung größtmöglicher Wiederverwendbarkeit Services höherer Abstraktionsebenen geschaffen werden (unter Berücksichtigung des Strict-Layer-Prinzips). Dann können diese Services veröffentlicht werden und es wird anderen Unternehmensbereichen oder Kunden ermöglicht die einzelnen Services zu nutzen. Maßgeblich sind also nicht technische Einzelaufgaben wie Datenbankabfragen, Berechnungen und Datenaufbereitungen, sondern die Zusammenführung dieser IT-Leistungen zu „höheren Zwecken“ – wie z.B. das Ausführen einer Bestellung oder das Buchen eines Fluges. Durch die lose Kopplung und Wiederverwendbarkeit der einzelnen Services entsteht eine hohe Agilität. Somit ist es möglich geänderte oder neue Geschäftsprozesse in kurzer Zeit abzubilden.

Rollen

SOA_Roles

  • Service Provider
    • stellt Geschäftsfunktionen als Services zur Verfügung
    • veröffentlicht Services (Schnittstellen)
  • Service Requestor
    • will Geschäftsfunktionen (Services) nutzen
    • nutzt die Schnittstellenbeschreibung, um den Service aufzurufen
    • kennt nur die Schnittstelle, nicht die Implementierung
  • Weitere Rollen
    • Service Registry – Verwaltet die Services aus technischer Sicht, im Gegensatz zu Repositories, die Services von einem geschäftlichen/fachlichen Standpunkt aus verwalten. Verwaltung aller technischen Details, die ein Service zur Laufzeit benötigt (Schnittstelle, Anbieter, IP-Adresse, Port, usw.)
    • Service Repository – enthält auch Information, die etwa zur Entwicklungszeit oder für das Management benötigt werden (z.B. Dokumentation, Versionierung, Auditing, Logging)

Die Services werden, wie schon geschrieben, von einem Client über das Netzwerk konsumiert. Für die Kommunikation zwischen Dienstnutzer und -anbieter können beliebige Netzwerkprotokolle genutzt werden, da diese lediglich als Transportvehikel für die eigentliche Nachricht des Services dient. Zur technischen Realisierung von Services stehen eine Vielzahl von Technologien zur Verfügung. Es kommen beispielsweise Standards wie CORBA, die auf binäre Protokolle für die Realisierung von verteilten Objektsystemen setzen, oder Messaging-Systeme, wie Microsoft Message Queuing Services, zur verlässlichen und asynchronen Übermittlung von Anfragen zum Einsatz. Daneben können auch Internet-Protokolle, wie FTP oder SMTP, die ursprünglich nicht für die Umsetzung von Services dieser Art gedacht werden, verwendet werden. Gerade bei der Kommunikation mit Altsystem kommen diese Protokolle immer wieder zum Einsatz. Für Neuimplementierungen werden Webservices bevorzugt. Der Grund dafür liegt in der Verwendung von offenen Standards wie HTTP, SOAP, XML, usw. welche eine weitaus größere Interoperabilität bieten. Daher nun einige Grundlagen zu den heute am meisten verwendeten Standards bzgl. Kommunikation und Datenübertragung. Hier nun zunächst einige Grundlagen zum HTTP-Protokoll für die Datenübertragung.

HTTP – Hypertext Transfer Protocol

Das Hypertext Transfer Protocol (HTTP, deutsch Hypertext-Übertragungsprotokoll) ist ein Protokoll zur Übertragung von Daten über ein Netzwerk. HTTP ist das wichtigste Transportprotokoll für webbasierte Inhalte. HTTP gehört der sogenannten Anwendungsschicht etablierter Netzwerkmodelle an. Die Anwendungsschicht wird von den Anwendungsprogrammen angesprochen, im Fall von HTTP ist das meist ein Webbrowser. Das zu Grunde liegende Prinzip ist simpel: Die Übermittlung der Daten erfolgt nach dem Request-Response-Schema. Der HTTP-Client sendet seine Anfrage (Request) an den HTTP-Server, der diese bearbeitet und eine Antwort (Response) zurücksendet.

Derzeit werden zwei Protokollversionen, HTTP/1.0 und HTTP/1.1, verwendet. Mit HTTP 1.0 wurde ein erweitertes Request-Response-Format eingeführt, das die Übermittlung von mehr Informationen in beide Richtungen erlaubt. Der eigentlichen Request folgt ein Satz von Headerfeldern, die beispielsweise die Übermittlung des Browsertyps erlauben. Seit Version 1.0 kennt HTTP auch die POST-Methode, mit der zum Beispiel Formulareingaben vom Browser zum Webserver gelangen. Bei HTTP/1.0 wird vor jeder Anfrage eine neue TCP-Verbindung aufgebaut und nach Übertragung der Antwort standardmäßig vom Server wieder geschlossen. Sind in ein HTML-Dokument beispielsweise zehn Bilder eingebettet, so werden insgesamt elf TCP-Verbindungen benötigt, um die Seite auf einem grafikfähigen Browser aufzubauen.

Weitreichendere Verbesserungen brachte die Einführung von HTTP/1.1. Eine der interessantesten Neuerungen: persistente Verbindungen. Während bei HTTP/1.0 jede Request über eine neue Verbindung zum Server übertragen wird, können in der aktuellen Version Verbindungen aufrechterhalten werden, um mehrere Requests zu übermitteln. Dies kann durch einen zusätzlichen Headereintrag (Keep-Alive) erreicht werden. Die Unterstützung auf Serverseite ist jedoch optional und kann in Verbindung mit Proxys Probleme bereiten. Über die neue Funktion Request Pipelining sendet ein Client nachfolgende Requests an den Server, bevor die Antwort des Servers auf die vorhergehende Anforderung auf der Clientseite eingetroffen ist. Im Zusammenspiel mit persistenten Verbindungen bringt das einen deutlichen Performancegewinn. Für das HTML-Dokument mit zehn Bildern wird so nur eine TCP-Verbindung benötigt. Zusätzlich können bei HTTP/1.1 abgebrochene Übertragungen fortgesetzt werden. Nachfolgend der Ablauf einer persistenten HTTP-Verbindung:

HTTP_Connection

HTTP-Methoden

MethodeBeschreibung
GETDie mit Abstand wichtigste Methode ist GET. Sie dient zur Anforderung einer Ressource (z.B. einer Datei) von einem Server, unter Angabe eines Request-URI. Die Länge des URIs ist je nach eingesetztem Server begrenzt und sollte aus Gründen der Abwärtskompatibilität nicht länger als 255 Bytes sein.
POSTDie POST-Methode schickt eine unbegrenzte Menge an Daten zur weiteren Verarbeitung zum Server (dies ist jedoch von der physikalischen Ausstattung des Servers abhängig). Diese Daten werden als Inhalt der HTTP-Nachricht übertragen und können beispielsweise aus Namen-Wert-Paaren bestehen, die aus einem HTML-Formular stammen. POST-Daten werden im Allgemeinen nicht von Caches zwischengespeichert.
HEADDiese Methode ist GET in seiner Funktionsweise sehr ähnlich. Einziger Unterschied: HEAD fordert lediglich den Header eines Dokuments oder Quelle an. Im Gegensatz zu GET übermittelt der Server aber nicht die eigentlichen Daten (Dokumentinhalt, BODY). HEAD eignet sich insbesondere dazu, die Größe von Quellen, Typ oder Objektattribute ausfindig zu machen. Der Server übermittelt auf eine HEAD-Anfrage die Metainformationen, die identisch mit den Informationen der GET-Request sind. So kann zum Beispiel schnell die Gültigkeit einer Datei im Browsercache geprüft werden.
PUTDie PUT-Methode dient dazu eine Ressource (z. B. eine Datei) unter Angabe des Ziel-URIs auf einen Webserver hochzuladen.
DELETEDie DELETE-Methode löscht die angegebene Ressource auf dem Server. Heute ist das, ebenso wie PUT, kaum implementiert bzw. in der Standardkonfiguration von Webservern abgeschaltet, beides erlangt jedoch mit RESTful Web Services und der HTTP-Erweiterung WebDAV neue Bedeutung.
TRACEÜber die TRACE-Methode kann der Client Requests verfolgen, die über mehrere Knotenpunkte laufen. Dies ist insbesondere bei der Übermittlung der Request über einen oder mehrere Proxyserver interessant. Das letzte Glied der Kette generiert die Antwort. Die TRACE-Methode dient in erster Linie der Diagnose von Client-Server-Verbindungen (Debugging von Verbindungen).
OPTIONSÜber die OPTIONS-Methode kann der Client Informationen über verfügbare Kommunikationsoptionen abrufen (liefert eine Liste der vom Server unterstützen Methoden und Features). So lassen sich insbesondere Beschränkungen von Quellen auf einem HTTP-Server oder auch einem Proxyserver ermitteln, ohne das eine bestimmte Aktion eingeleitet oder gar ein Datentransfer stattfindet.
CONNECTDie CONNECT-Methode ist in der HTTP/1.1-Spezifikation für Verbindungen reserviert, bei denen Proxyserver dynamisch als Tunnel agieren. In der Praxis kann es sich beispielsweise um SSL-Tunnel handeln. Der Tunnelmechanismus ist in der ersten Linie als Durchgang für SSL-gesicherte Verbindungen durch eine Firewall gedacht.

Beispiel einer Konversation

Hier nun ein kleines Beispiel für die Übertragung normaler Webseiten im HTML-Format. Wenn ein Webbrowser eine Webseite anfordert, könnte der HTML-Request zum Beispiel folgendermaßen aussehen (bei „GET“ würden eventuelle Parameter an die URL angehängt, bei „POST“ würden sie im HTTP-Header übertragen):

HTTP_Request

Der Webserver könnte als Antwort zum Beispiel Folgendes schicken:

HTTP_Response

Da HTTP nur ein Transportprotokoll zur Sicherstellung der vollständigen und fehlerfreien Übertragung von beliebigen Nachrichten darstellt, sagt es über die Struktur und Inhalt der übertragenen Nachricht nichts aus. Die eigentliche Nachricht wird deshalb noch ein Webservice-Protokoll eingepackt. Denkbar sind dabei REST, JSON oder SOAP-basierte Nachrichten. Daher nun einige Grundlagen zu diesen Standards.

SOAP

Bei SOAP handelt es sich um einen XML-basierten Standard zu Kommunikation zwischen Systemen. Im Zuge dessen können Nachrichten ausgetauscht oder entfernte Prozeduren angestoßen werden (Remote Procedure Call, RPC). Die gängigste Kombination ist SOAP über HTTP und TCP als Transportprotokoll (prinzipiell ist SOAP jedoch protokollunbahängig). SOAP kann beispielsweise auch über SMTP übertragen werden, um eine asynchrone Kommunikation zwischen Systemen zu realisieren. Ursprünglich stand SOAP für Simple Object Access Protocol. Die Abkürzung SOAP wird offiziell seit Version 1.2 nicht mehr als Akronym gebraucht, da es erstens (subjektiv) keineswegs einfach (Simple) ist und zweitens nicht nur dem Zugriff auf Objekte (Object Access) dient.

Eine minimale SOAP-Nachricht besteht aus einem Envelope genannten Element. Kind dieses Elements muss ein Body-Element sein. Optional kann zuvor ein Header-Element stehen. In diesem können Meta-Informationen, beispielsweise zum Routing, zur Verschlüsselung oder zu Transaktionsidentifizierung, untergebracht werden. Im Body-Element sind die eigentlichen Nutzdaten untergebracht. Innerhalb des Body-Elements können sowohl Informationen zum Datenaustausch, als auch Anweisungen für einen entfernten Prozeduraufruf stehen. Dies ist vom Empfänger entsprechend zu interpretieren. Nachfolgend der grundlegende Aufbau einer SOAP-Nachricht:

Im folgenden Beispiel nun ein SOAP-Request (in dem gezeigten Beispiel wird eine Anfrage an den Microsoft Bing-Übersetzer veranschaulicht). Der Body beinhaltet ein Element Translate, das auf eine Service-Operation mit demselben Namen verweist. Die Elemente innerhalb von Translate entsprechen den erwarteten Parametern und den entsprechenden Parameterwerten (die Anfrage enthält kein Header-Element):

In dem oben gezeigten Beispiel wird ein Text zwecks Übersetzung an den Service geschickt. Das Text-Element enthält den zu übersetzenden Text und das From– bzw. To-Element enthalten die Sprachkennzeichen für die Übersetzung (z.B. Übersetzung von Englisch in Deutsch). Nachfolgend die Antwort, die der Service zurückliefert:

Im Body befindet sich das Element TranslateResponse, welches wiederum das Element TranslateResult beinhaltet. Letzteres enthält den übersetzten Text.

Ein Beispiel für den Zugriff auf einen SOAP-Service ist im folgenden Beitrag zu finden: .NET: Zugriff auf einen bestehenden SOAP Webservice (Bing Translator Service inkl. Demoanwendung)

RESTful Web Services

Representational State Transfer (REST) ist ein Architekturstil für Webanwendungen. REST sieht eine direkte Verwendung von HTTP zur Arbeit mit Ressourcen vor. REST gilt in seiner Konsequenz als eine wichtige Richtlinie für die Nutzung von Web-Standards, in Abgrenzung zu vielen historisch gewachsenen Verfahren. Daraus folgt teils eine Rückbesinnung auf grundlegende Web-Technologien, die die Implementierung verteilter webbasierter Systeme vereinfachen soll. REST ist kein Produkt oder Standard. REST beschreibt, wie Web Standards in einer Web gerechten Weise einsetzt werden können.

REST-konforme Dienste müssen einige Operationen vorsehen, die auf alle Ressourcen angewendet werden können. Zum Arbeiten mit diesen Ressourcen sieht HTTP generische Befehle, wie GET, POST, PUT und DELETE vor (siehe dazu die oben stehende Tabelle). Diese Befehle werden auch als HTTP-Verben bezeichnet. Die Semantik des HTTP Protokolls wurde in REST übernommen. Mit diesem begrenzten Vorrat von vier Methoden müßten alle Anwendungsfälle generisch abgedeckt werden können. Viele Anwendungen, die SQL verwenden benutzen auch nur die generischen Befehle SELECT, INSERT, UPDATE und DELETE.

HTTP schreibt vor, dass GET „sicher“ (englisch safe) sein muss, was bedeutet, dass diese Methode nur Informationen beschafft und keine sonstigen Nebeneffekte verursacht. Die Methoden GET, HEAD, PUT und DELETE müssen laut HTTP-Spezifikation idempotent sein, was in diesem Zusammenhang bedeutet, dass das mehrfache Absenden der gleichen Anforderung sich nicht anders auswirkt als ein einzelner Aufruf.

Sämtliche Dokument-Typen können in REST Anwendungen übertragen werden. In welchen Format dieses Ressourcen vorliegen müssen, wird jedoch nich definiert bzw. vorgeschrieben. Es kommen aber oft Standards wie XML, JSON, ATOM oder RSS zum Einsatz (es sind aber auch durchaus andere Formate denkbar). Jede REST-Nachricht enthält dabei alle Informationen, die für den Server bzw. Client notwendig sind, um die Nachricht zu interpretieren. Für die Interpretation einer Nachricht ist kein Wissen über vorherige oder spätere Nachrichten notwendig.

Literaturverzeichnis und Weblinks

Abk.Quelle
[1]Wikipedia: Serviceorientierte Architektur
[2]Wikipedia: HTTP
[3]Wikipedia: SOAP
[4]Wikipedia: Representational State Transfer
[5]Manfred Steyer, Holger Schwichtenberg, Matthias Fischer, Jörg Krause: Verteilte Systeme und Services mit .NET 4.5, 2. Auflage, Hanser Verlag, ISBN 978-3-446-43443-1
[6]Service-orientierte Architekturen mit Web Services, 4. Auflage, Ingo Melzer, Spektrum Akademischer Verlag Heidelberg, ISBN 978-3-8274-2549-2
Fork me on GitHub