SOA and ROA oder ist REST der bessere Web Service

Es gibt eine Vielzahl von Publikationen welche REST mit SOAP und WS* vergleichen, aber dies erscheint etwas zu einfach. Es gibt zwei Hauptansätze welche in letzter Zeit erschienen sind - true REST und REST als Technologievorstoß für Services (auch bekannt als REST Web Services). In diesem Artikel werde ich diskutieren, ob einer dieser Ansätze die SOA Implementierung verbessern kann.

True REST für SOA

Ein true REST ist effektiv eine Implementierung einer Resource-orientierten Architektur und nicht bloß eine Technologieentscheidung. Damit ist die richtige Frage wenn wir über true REST diskutieren, ob das dem anheftende ROA auch gut zu einer SOA Implementierung passt?

Um das Problem korrekt anzupacken, müssen wir uns als erstes in Errinnerung rufen, das die SOA Architektur auf der funktionalen Gliederung der Unternehmens-Geschäfts-Architektur basiert und damit zwei high-Level Abstraktionsebenen einführt: Unternehmens-Geschäfts-Services und Geschäftsprozesse. Unternehmens-Geschäfts-Services repräsentieren existierende IT Kapazitäten welche wiederum den Geschäftsfunktionen eines Unternehmens zugeordnet sind. Und Geschäftsprozesse, welche die Geschäftsservices darstellen und damit die einzelnen Funktionen eines Geschäftes definieren.

REST andererseits ist ein Set von Architekturprinzipien ausgedrückt als resourceorientierte Architektur (ROA). ROA basiert per Konzept auf Resourcen. Jede Resource ist eine direkt zugängliche, verteilte Komponente welche über ein allgemeingültiges Interface angesprochen werden kann. Damit ist das Hauptanliegen von ROA eine resourcenbasierte Untergliederung.

Wie nun mittels true REST auch SOA implementieren ist die Kernfrage die es zu beantworten gilt. Wie kann also die Beziehung zwischen einem Service und einer Resource definiert werden?

Services versus Resources

Was ist ein Service? Im einfachsten Fall kann ein Service als unabhängig entwickelte, deployte, gemanagte und gewartete Software Implementierung speziell für businessrelevante Funktionalitäten für ein Unternehmen als Ganzes betrachtet werden, welches Seitens des Designs integrierbar sein muss. Ein Service kann mittels eines Verbs benamt werden (z. B. "prüfeKundenKredit").

Ein Service ist weniger ein Set von APIs, sondern eher ein architektonisch (Einheit von Design, Implementierung und Wartung) und Deployment Artifakt, welches für die Implementierung von Unternehmenslösungen genutzt wird. Die Service Funktionalität ist über ein Serviceinterface definiert, welches wiederum mittels diverser Lösungen implentiert werden kann. Es gibt in diesem Zusammenhang im wesentlichen zwei Wege ein Interface zu definieren - RPC oder Messaging Style. PRC-Style nutzt die Service Aufruf Semantik und sind durch ein Set von Parametern im Serviceinterface definiert. Im Fall des Messaging-Style ist das Serviceinterface vorgeschrieben und performed im wesentlichen das "execute" mit einem XML Dokument als In- und Output.

Historisch werden Services häufig als Sammlung von Methoden definiert, aber wie bereits erläutert sind diese Methoden unabhängig voneinander und dienen als Namenskonvention zur Vereinfachung von Managementmethoden.

Was ist eine Resource?

Im einfachsten Fall kann eine Resource als direkt zugängliches, unabhängig entwickeltes, deploytes, gemanagtes und gewartetes Software Artifakt betrachtet werden, welches bestimmte Daten anbietet. Eine Resource kann als Substantiv benamt werden (z. B. "Arzttermin"), welches die Daten des Dienstes beschreibt. Eine Ressource kann darüberhinaus mit weiteren Ressourcen verbunden sein und eine Referenz auf diese unterstützen. Im Klartext ist eine Ressource sehr ähnlich zu einem Objekt aber mit einer vordefinierten (CRUD) Interface Semantik.

Die Semantik in REST basieren auf einem Set von HTTP Operationen:

• createResource - PUT,
• getResourceRepresentation - GET,
• deleteResource - DELETE (POST wenn verlinkte Ressourcen betroffen sind),
• modifyResource - POST,
• getMetaInformation - HEAD.

Eine Ressource wird durch seine URL und die Definition der In- und Outputs bestimmt. Anders als bei einem Service, bei welchem die Methoden komplett unabhängig voneinander sind und auch als unabhängige Endpoints deployed werden können. Methoden einer Ressource entsprechen dem OO Design, was bedeutet, dass alle Methoden in der darunter liegenden Ressource zu existieren haben (unter der selben URL).

Hauptunterschiede zwischen Ressourcen and Services

Basierend auf den obigen Definitionen für Resourcen und Services scheint es ziemlich offensichtlich, dass es erhebliche Unterschiede zwischen diesen gibt. Im Folgenden gehe ich erst auf die Unterschiede ein und diskutiere dann was dies für die Architektur bedeutet.

“REST ist nicht nur nicht service-orientiert, sondern Service-Orientierung ist irrelevant für REST!”

Eine weitere häufig anzutreffende Erklärung ist:

"Wenn WS-* das RPC des Internets ist, dann ist REST das DBMS des Internets... Traditionelle SOA basierende Anwendungen interagieren mittels Prozeduren oder Methoden miteinander. REST hingegen betrachtet jedes Software Artefakt als Tabel, mit welchem wiederum per SELECT, INSERT und DELETE (GET, PUT, POST, DELETE) kommuniziert wird." Und wo ist dann die Businesslogik? In den Stored Procedures? Nein, sondern in den Triggern."

Hier möchte ich eine etwas andere Analogie aus dem J2EE bereich verwenden. Wir können Services als Stateless Session Beans und Resources als Entity Beans betrachten.

Services - Session Beans - dienen als Controller welcher angeforderte Operationen ungeachtet der darunter liegenden Resourcen ausführt. Beispielsweise ein Konto - Buchungs - Service könnte die Kontonummer und den abzubuchenden Betrag nehmen und das entsprechende Konto belasten. Ein einzelner Service kann dann alle Buchungen für existierende Konten vornehmen.

Resources - Entity Beans - dienen als Datenzugriffsmechanismus für eine gegebene Instanz eines vorgegebenen Typs. Beispielsweise um ein bestimmtes Konto zu belasten ist es wichtig, eine Resource zu finden, welche das Konto repräsentiert, um den entsprechenden Betrag updaten zu können. Eine zusätzliche Einschränkung ergibt sich daraus, dass anders als bei einer Entity Bean, welche jede benötigte Methode implementieren kann, eine REST Resource nur aus einer einzigen Modify-Resource-Methode besteht. Das heißt, das die aktuelle Geschäftsoperation, in diesem Fall die Abbuchung, in dem Request untergebracht werden muss.

Was heisst das?

Basierend auf dem Vorangegangenen ist es unmöglich ein SOA System welches REST nutzt zu bauen. Es ist mölgich ein System zu bauen, aber es wäre kein SOA. Beide werden mit den geschäftsabhängigen Komponenten starten, aber aufgrund der Tatsache, dass sie komplett unterschiedliche Ansätze zur Darstellung ihrer Komponenten nutzen, werden sie in komplett unterschiedlichen Architekturen münden und damit unterschiedlichen Komponenten und Konnektoren.

Nur weil wir versuchen das selbe Problem zu lösen und beide Ansätze auf einer Komponentenzerteilung aus Geschäftsprozesssicht basieren meint nicht, dass das Ergebnis zur selben Architektur fühen wird.

Eine andere Frage ist, ob es möglich ist, eine komplette Anwendung nur mittels true REST zu bauen. Basierend auf dem Untersuchten ist damit die Frage, ob es möglich ist, ein komplettes System nur eine Datenbank oder Entity Beans nutzen zu lassen. Sicherlich könnte man, aber dies würde zusätzlichen Codes in Stored Procedures/Trigger bedürfen, welche weitere Aktionen über das reine Update hinaus vornehmen. Datenupdates werden also interpretiert und durch weitere Aktionen ergänzt - wie es für true REST Anwendungen typisch ist.

Daraus resultiert, das eine REST basierende Implementierung nur selten true REST ist; typischer Weise sind zumindest einige REST Web Servcies enthalten. Was bedeutet es nun ein REST Web Service zu sein?

REST Web Services

Der REST Web Service Vorstoß ist der Versuch, REST nur als reine Kommunikationstechnologie zu nutzen und damit SOA abzubilden. In diesem Fall definieren sich Services als SOA basierende Komponentenzerteilung und REST-based Web Services werden als Transportmittel genutzt.

Obwohl dies typischerweise auf REST verweist, hat dieser Vorstoß nichts mit true REST zu tun und ist eher verwandt mit POX (plain old XML over HTTP) mit Ausnahme des XML. Üblicherweise werden diverse andere Marshalling Typen von JavaScript Objekten bis hin zu JSON Objekten genutzt. Die einzige Gemeinsamkeit bilden die HTTP Methoden GET und PUT.

JSON zu benutzen wurde in der letzten Zeit ein sehr populärer Vorstoß basierend auf der Tatsache, dass die sich explosionsartig im Web verbreitende Technologie AJAX dieser Notation bedient. Des Weiteren beinhalten die meisten Browser bereits JSON Support. Seit dem es eine nicht triviale Aufgabe ist mittels JavaScript XML zu nutzen, ist es deutlich einfacher für web-basierte Implementierungen auch JSON-basierten REST Web Service zu nutzen.

Was ist nun der eigentliche Unterschied?

In Publikationen beschriebene Unterschiede zwischen SOAP und REST verweisen typischerweise auf die folgenden Vorteile von REST Web Services: •“Lightweight – nicht zu viel xml Markup Language •Lesbare Resultate •Einfach zu bauen – es werden keine Toolkits benötigt”

Meines Erachtens sind diese Unterschiede entscheidend (Ich werde sie später in diesem Artikel detaillierter diskutieren), da der Hauptunterschied zwischen SOAP und REST der Fakt ist der dazu geführt hat, dass REST direkt auf dem HHTp Protokoll implementiert wurde, wohingegen SOAP eine Abstraktionsschicht implementiert und damit auf andere Transportlösungen setzt. Diese zusätzliche Abstraktionsschicht, welche Decoupling zwischen existierenden Übertragungen unterstützt. Damit sind SOAP-basierte Implementierungen die Wurzel der Unterschiede zwischen SAOP und REST Web Services.

Die Meinungen über die Abstraktionsschicht gehen weit auseinander. Die REST Fraktion betrachtet es als Over-Enginieering und behauptet, dass es keinen wahren Nutzen mit sich bringt. Sie sind der Meinung, dass HTTP bereits alle notwendigen Feature für Service Interaktion bereit stellt. Die SOAP Fraktion auf der anderen Seite argumentiert, dass HTTP nicht der einzige Transport ist welcher typischer Weise für Service Interaktionen gebraucht wird insbesondere innerhalb der Enterprise Umgebung. Folglich ist es unumgänglich auf eine portable, erweiterbare Abstraktionsschicht zu setzen, um robuste featurereiche Service Interaktionen abzubilden.

Beide Standpunkte haben durchaus ihre Berechtigung, entsprechend meiner Erfahrung jedoch gelingt der Versuch SOA Implementierungen auf einen einzelnen HTTP-Transport zu beschränken in der Praxis meist nicht. HTTP ist zwar allgegenwärtig und braucht üblicherweise keine zusätzlichen infrastrukturellen Investitionen aber es ist einfach nicht zuverlässig (HTTP-R ist nicht weit verbreitet), es ist nur synchron, temporäres Coupling, keine Transaktionskontrolle und so weiter.

Hinzu kommt, selbst wenn HTTP die reine schlanke Implementierung des Transportes ist, der SOAP Kontainer kann sehr nützlich und leicht handhabbbar werden, um eine Trennung der Geschäfts- (SOAP Body) und der Infrastruktur out-of-bound Daten (SOAP Headers) zu erreichen. Und schlussendlich, sollte die eigene Implementation all dies nicht brauchen, der Overhead des SOAP Kontainers ist minimal (2 Tags), unterstützt aber eine elegante Weise weitere Daten hinzuzufügen wenn der Bedarf ensteht.

Am Ende des Tages ist die Datentrennung des SOAP Kontainers nach Geschäftslogik und Infrastruktur ein mächtiges Paradigma, welches auch häufig in der REST Web Service Welt genutzt wird.

Weitere Unterschiede

Es sei mir gestattet eine letzte Betrachtung der Unterschiede zwischen SOAP und Rest Web Service wie sie häufig in Publikationen zu finden ist, vorzunehmen.

Einfachheit

Eine populäre Meinung ist, dass REST deutlich einfacher ist als SOAP. Dies ist dem Fakt geschuldet, dass REST kein WSDL oder irgend ein anderes Interface benötigt. Derartige Aussagen sind bestenfalls naiv. Es spielt keine Rolle welche Technologie für die Kommunikation zwischen Service Konsument und Anbieter genutzt wird, beide müssen sowohl der Syntax als auch der Semantik zustimmen, um Nachrichten austauschen zu können, was wiederum einem Interface gleich kommt. Im Fall von REST kommen hierfür zwei Ansätze in Frage: •Ein Interface in einem Textfile definieren und manuell das Data Marshalling/Unmarshalling auf Basis eines allgemeinen Interfaces, welches in dem Interface Dokument beschrieben wird. Dennoch wird so ein Ansatz häufig von REST Jüngern befürwortet, da derartige Implementierungen selten über 10 bis 15 Elemente hinaus gehen. Darüber hinaus ist so ein Ansatz äußerst Fehler anfällig. Als Resultat haben die meisten verfügbaren REST Frameworks diesen Ansatz aufgegeben, um lieber auf neuere Ansätze zu warten. zu implementieren. •Ein Interface auf XSD Basis definieren und die Generierung des Daten Marshalling/Unmarshalling dem preferierten Framework überlassen (z. B. JAX-B oder Castor im Fall von XML bzw. Payload oder Jackson im Fall von JSON). Dieser Ansatz ist im Endeffekt eine minimalistische Version eines WSDL und benötigt ungefähr den gleichen Aufwand wie eine SOAP basierte Implementierung. Im Prinzip wird exakt der gleiche Ansatz oft für SOAP basierte Anwendungen genutzt, indem ein einzelnes Interface und ein Command Pattern für die Ausführung genutzt wird. Die Erweiterung des Ansatzes besteht dann in der Nutzung von WSDL2.0 und/oder WADL für REST.

Another common complaint about SOAP is perceived complexity of WS* standards [15]. Although there is no single spec that lays out the key WS*standards and their interrelationships, there is a standard for a majority of service interaction use cases. Granted, the choosing of an appropriate WS*standard and its usage might require some extra understanding/implementation time, but [16]:

“Arguing simplicity versus standards is ridiculous in the war between REST and SOA because simplicity without standards is just as detrimental to the costs and manageability of an application “

So, with the exception of the most simplistic examples like “temperature converters”, REST is not any more simple than SOAP.

Lightweight

Ein anderer Grund dafür, dass viele REST Jünger behaupten REST sei eine Alternative zu SOAP ist der Tatsache geschuldet, das in REST sowohl Request and Response sehr kurz sein können. Dafür gibt es zwei Gründe: •SOAP benötigt einen XML Wrapper um jeden Request und Response herum, was wiederum die Größe der Nachrichten steigen lässt. Dies ist sicherlich unstrittig, wichtig hierbei ist jedoch nicht wieviele Bytes der Wrapper hinzufügt sondern wieviel Prozent Overhead kreiert wird. Die Wrapper Größe ist Konstant und das Wachstum der Nachrichten Größe ist schlussendlich vernachlässigbar. Bedenkt man das ein typischer Service selten einen großen Request und Respons hat, so kann der Overhead aufgrund des SOAP Kontainers getrost vernachlässigt werden. •SOAP ist ein XML basierendes Nachrichtensystem welches verbose Encoding nutzt. REST auf der anderen Hand, unterstützt eher leichtgewichtigere Alternativen wie JSON. Ebenfalls ist es wahr, dass die Benutzung des Message Transmission Optimization Mechanism MTOM von den meisten SOAP Frameworks unterstützt wird, was wiederum erlaubt, Nachrichten in kleinste XML basierende SOAP Kontainer/Header/Body Teile und zugehörige Nachrichteninhalte zu zerteilen. Auf diese Weise kann der Inhalt wiederum in MIME Types encoded werden, was wiederum JSON oder Binär Streams etc. einschließt.

Dennoch in der Theorie ist REST leichtgewichtiger als SOAP, wohingegen in der Praxis mittels einiger fortgeschrittener SOAP Design Techniken die Unterschiede zwischen realistischen REST and SOAP Anwendungen minimiert werden können.

Einfach zu bauen - es werden keine Toolkits benötigt

Da REST auf HTTP basiert behaupten REST Jünger immer wieder, dass gewohnte Techniken wie Java Servlet API und Java HTTP Support eingesetzt werden können, um zum Einen REST Services zu bauen und zum Anderen REST Clients ohne spezielle Toolkits erstellt werden können. Dies ist wahr vorausgesetzt jemand versucht manuell den Ein- und Ausgang von Nachrichten sowie dessen Marshalling zu implementieren. Das gleiche kann mit SOAP Services gemacht werden. Jedoch die Wenigsten wollen derartig rudimentären Code schreiben, was dazu führt, dass sowohl für REST als auch SOAP Toolkits eingesetzt werden.

Schlussfolgerung

REST kann eingesetzt werden sowohl für System Design Ansätze welche ROA (true REST) nutzen, als auch SOA Design Ansätze welche REST Technologien (REST Web Services) nutzen. Beide Ansätze haben ihre Berechtigung aber keiner wird den härtesten Part, das Definieren der Geschäfts- Services/Resourcen in Abstimmung mit dem Unternehmens Geschäftsmodell wesentlich verändern. Es gibt Anwendungsfällle sowohl für ROA als auch SOA, aber am Ende des Tages bleiben es zwei sehr unterschiedliche Ansätze.