Unter dem Begriff SOA werden im Allgemeinen der Ansatz und die Absicht verstanden, die IT eines Unternehmens nicht als eine Sammlung individueller, monolithischer Anwendungen zu organisieren. Stattdessen sollen die Funktionen, die zur Umsetzung der Geschäftsprozesse benötigt werden, als möglichst konkrete Einzeloperationen (Services) mit hohem Wiederverwendungspotential implementiert werden. Die Umsetzung der komplexeren Geschäftsprozesse erfolgt dann durch das vordefinierte Zusammenspiel dieser Services.
SOA macht keine Vorgaben zur technischen Umsetzung. Häufig erfolgt die Umsetzung auf Basis von SOAP-Webservices. Dabei werden Dienste, deren Schnittstellen, Operationen und Datenobjekte mithilfe der WSDL definiert.
Da diese wiederum unabhängig von der technischen Realisierung ist, können über WSDL definierte Dienste miteinander kommunizieren, auch wenn einer von ihnen in Java implementiert ist und der andere in C# oder PHP. Die Integration von Diensten über Technologiegrenzen hinweg ist dadurch relativ einfach möglich.
Integration mit RESTful Services
Implementiert man seine Services als RESTful Services, hat man keine WSDL zur Schnittstellendefinition. Was gäbe es auch groß zu definieren? Da REST auf dem HTTP-Protokoll aufsetzt, sind die möglichen Operationen für alle Dienste dieselben: GET, PUT, POST, DELETE, usw.
Was bei REST notwendig ist, ist die Beschreibung der Ressourcen, auf denen die genannten Operationen ausgeführt werden. Ressourcen sind beispielsweise die Repräsentation eines Kunden, eines Vertrages oder einer Bestellung. Es muss definiert werden, wie eine solche Ressource strukturiert ist. Formate wie XML oder JSON bieten sich dafür an. Der Zugriff auf eine Ressource erfolgt, durch HTTP vorgegeben, über einen URI. Zuletzt ist definiert, welche Operationen an einem URI erlaubt sind.
Eine Service-Landschaft, die auf RESTful Services basiert, lässt sich in etwa mit dem World Wide Web vergleichen. Dort finden sich unzählige Webseiten (vgl. Ressourcen), die über ihren URI eindeutig identifiziert werden können. Dieser URI ist ebenfalls die Basis für die Verlinkung der Ressourcen untereinander.
Über Suchdienste wie Google kann man sich nun auf die Suche nach einer bestimmten Ressource machen:
Web Suche nach Sheldon Cooper
Alle gefundenen Ressourcen lassen sich ohne spezialisierte Client-Software korrekt interpretieren. Man benötigt lediglich einen HTTP-Client, ein Anwendungs-spezifisches Set an Operationen existiert nicht. Die hier gefundenen Daten liegen nicht in einem einzelnen Informationssystem, sondern auf tausenden von getrennten Webservern. Da sie jedoch alle über das HTTP-Protokoll erreichbar sind, können sie von einem einzelnen Dienst durchsucht und die Suchergebnisse in einheitlicher Form dargestellt werden.
REST im Unternehmen
Man stelle sich das im Unternehmens-Umfeld vor: Alle Ressourcen, sprich Kunden-, Auftrags- und sonstige Stammdaten können über REST-Operationen abgefragt und auch manipuliert werden. Auch für die Maschinen-zu-Maschinen-Kommunikation ist das eine große Vereinfachung im Vergleich zu SOAP. Das Heraussuchen von Ressourcen, also beispielsweise Kundendaten, über mehrere Anwendungen hinweg, kann so einfach werden wie eine Suche in Google.
Sofern die RESTful-Services geeignete Meta-Informationen liefern, sich also im geeigneten Umfang selbst beschreiben und sofern es Service- und Daten-Repositories gibt, kann eine IT-Service-Landschaft zu ungeahnter Transparenz gelangen.
