Kleinteiliges aus der Wolke: Bereitstellen von Geschäftslogik via REST und dem RAD Server

Den Wandel in den Softwarearchitekturen haben wir im Intro bereits angedeutet. Dabei kann man die wesentlichen Schritte anhand der folgenden Meilensteine kompakt beschreiben. Anwendungssysteme, welche gewissermaßen keine explizite Trennung in unterschiedliche Teilsysteme aufweisen, bezeichnet man als monolithische IT-Systeme. Die typischen Funktionen eines solchen Anwendungssystems – also Datenhaltung, Anwendungslogik und Benutzeroberfläche – sind in diesem Fall eng gekoppelt und weitreichend zu einem komplexen Gesamtsystem miteinander verschmolzen (s. Abb. 1).

Mit einer solchen Architektur kann man i. d. R. nicht mehr die heutigen Anforderungen an ein flexibles Softwaresystem erfüllen. Das gesamte System stellt sich als ein großer und kaum zu durchschauender Block dar. Ein solches IT-System führt zu folgenden Nachteilen:

• Hohe Komplexität: Das Softwaresystem ist komplex. Die fehlende Aufteilung in Einzelmodule führt dazu, dass diese nicht reduziert wird.
• Schlechte Wartbarkeit: Die Wartung und Fehlerbereinigung stellen sich als sehr schwerfällig dar. Es gelingt nicht, einzelne Teile der Anwendung gegen neuere Technologien auszutauschen, ohne dass dies direkte Einflüsse auf andere Bestandteile der Software hat. Anpassungen an einer Stelle im Quellcode lösen gewissermaßen eine Kette von notwendigen Folgeanpassungen aus.
• Schwierige Wiederverwendung: Die Wiederverwendung einzelner Softwarekomponenten ist bei einem solchen komplizierten monolithischen Gesamtsystem ausgeschlossen. Entwickler können eine einmal erarbeitete Lösung für eine ähnliche Problemstellung nicht wiederverwenden, sondern müssen jedes Mal von vorn beginnen.
• Inflexibilität: Eine Erweiterbarkeit und eine Skalierbarkeit sind stark eingeschränkt.
• Systemgebunden: Nutzer wollen heute auf unterschiedlichsten Geräten, vom Smartphone bis zum Desktop und den verschiedensten Betriebssystemen ihrer Wahl arbeiten. Die Bindung an eine Systemumgebung auf Clientseite schränkt diese Wahlmöglichkeit stark ein.

Monolithische IT-Systeme sind heute nicht mehr Stand der Technik. Oft sind diese automatisch auf dem Wege der Implementierung irgendwie entstanden. Dennoch sind noch viele solcher Systeme im Einsatz. Sie werden als Altsysteme bzw. Legacy-Systeme bezeichnet. Ihre Modernisierung und Anpassung ist eine der schwierigsten und komplexesten Aufgaben der heutigen Softwareentwicklung. Trotzdem muss es im Sinne des Investitionsschutzes das Ziel sein, bei der Migration dieser Systeme eine möglichst große Quellcodebasis zu erhalten und erfolgreich zu transformieren. Besser ist eine Aufteilung der Gesamtapplikation in Schichten, üblicherweise für die Datenhaltung, die Verarbeitung und die Präsentation (Abb. 2).

Der Einsatz von Web-Applikationen und die Verwendung von Apps für mobile Geräte zwingen gewissermaßen zu einer Aufteilung der Aufgaben des Systems. Aufgrund der Beschränkung in den Ressourcen müssen große Teile der Datenbereitstellung und Businesslogik an Dienste ausgelagert werden.

Kommen wir zu Microservices. Eine eindeutige Definition gibt es nicht. Wird ein Anwendungssystem nach diesen Prinzipien aufgebaut, dann geht man von einer sehr breiten und tiefen Modularisierung über alle Komponenten des Softwaresystems aus. Die einzelnen Module werden einzeln und unabhängig voneinander in Produktion gebracht und weiterentwickelt. Die Services können dabei flexibel durch unterschiedlichste Anwendungssysteme, welche nicht nur auf das eigene Unternehmen beschränkt sind, benutzt werden. Die Integration erfolgt üblicherweise über RESTful http, d. h. über eine einheitliche Schnittstelle. Die eigene Anwendung wird damit gewissermaßen zum Service, welcher sich wiederum aus der Nutzung anderer Dienste zusammensetzt (Abb. 3).

Für die Nutzung eines Service spielt dessen technische Umsetzung keine Rolle. Unterschiedliche Betriebssysteme und die Bereitstellung auf verschiedenen Technologien sind nicht hinderlich. Einzelne Services können ausgetauscht werden oder werden unabhängig vom Gesamtsystem aktualisiert. Sofern man die Services von Drittanbietern nutzt, gibt man gewissermaßen die gesamte Verantwortung für den Betrieb und die weitere Entwicklung weiter. Sofern sich die Schnittstelle nicht ändert, haben Anpassungen am Dienst keine Auswirkungen auf die nutzende Software. Ist man nicht mehr mit den Leistungen des Dienstes zufrieden, kann man diesen gegen einen anderen tauschen. Anpassungen sind nur an den Stellen im Quelltext notwendig, welche mit dem Dienst kommunizieren.

REST als Basis der Kommunikation

Werden Client und Server über Netzwerke (Internet) miteinander vermittelt, dann basiert die Nutzung des entfernten API meist auf der Basis von REST. REST hat sich dafür als Standard etabliert und steht als Abkürzung für REpresentational State Transfer. Schnittstellen (API), welche auf REST setzen, werden im Entwickler-Jargon auch gern als "RESTful" bezeichnet. Derartige Implementierungen setzen wiederum auf standardisierte Verfahren, wie HTTP/S, URI, JSON oder XML. REST basiert auf folgenden wichtigen Prinzipien [1]:

• Client-Server-Modell: Die Kommunikation erfolgt auf der Basis eines Client-Server-Modells. Das Ziel ist eine flexible und generische Nutzung der Services über Plattformgrenzen hinweg.
• Zustandslosigkeit: Die Kommunikation zwischen Client und Server ist stets zustandslos. Jede Anfrage vom Client an den Server muss vollständig sein. Der Server kann auf keine vorherige Anfrage zurückgreifen. Die Vorteile sind eine hohe Zuverlässigkeit und eine einfache Skalierbarkeit. Als Nachteil ergibt sich eine höhere Netzbelastung, da jede Anfrage von einem vollständigen Datensatz begleitet werden muss.
• Caching: Clients können Antworten des Servers speichern. Damit können Netzausfälle überbrückt oder ein zeitweiser Offline-Betrieb ermöglicht werden. Diese zwischengespeicherten Daten können dann bei einer erneuten Anfrage alternativ statt einer neuen Antwort vom Server verwendet werden. Informationen müssen als cacheable oder non-cacheable gekennzeichnet werden.
• Einheitlichkeit: Restkonforme Services (RESTful API) nutzen eine einheitliche Schnittstelle, welche vom bereitgestellten Dienst entkoppelt ist. Damit entsteht die Möglichkeit einer universellen Verwendung.
• Mehrschichtig: Das Gesamtsystem besteht aus einzelnen Schichten. Komponenten kennen nur verknüpfte andere Komponenten. Es sinkt die Systemkomplexität und es wird einfacher, Erweiterungen durchzuführen.

Ein RESTful-API wird i. d. R. per http bzw. https umgesetzt. Die Services werden per URI und den üblichen http-Methoden GET, Post, PUT usw. genutzt, d. h. der Client sendet eine Anfrage (Request) an den Server und erhält eine Antwort (Response). Ein Request besteht aus vier Bestandteilen (Abb. 4).

Die Bestandteile sind: Der Endpunkt (endpoint), die Methode (method), der Header (header) und die Daten (data). Der Endpunkt setzt sich aus dem root-endpoint, dem path und möglichen Parametern zusammen. Beispielsweise ist https://api.github.com der root-Endpoint von GitHub und /users/veikkoef/repos der path zu den Repositories der Autoren. Zusammen ergibt dieses https://api.github.com/users/veikkoef/repos. Es können noch Parameter nach dem folgenden Muster folgen: ?query1=value1&query2=value2. Bei den http-Methoden hat man die Wahl zwischen GET, POST, PUT/ PATCH und DELETE. GET steht für Read-Operationen. Da GET-Requests nur lesend auf den Server zugreifen, können sie beliebig oft abgeschickt werden. GET ist die standardmäßige Methode. POST wird für Create-Operationen, also das Erzeugen eines Datensatzes eingesetzt. Es können beispielsweise durch einen POST-Aufruf Felder in einer Datenbank verändert oder Prozesse auf dem Server gestartet werden. PUT/ PATCH verwendet man für Update-Operationen und DELETE für das Löschen von Daten. Der Header dient zur Bereitstellung von Informationen für den Client und den Server. Dieser kann für viele Zwecke verwendet werden, zum Beispiel zur Authentifizierung und Bereitstellung von Informationen über den nachfolgenden Inhalt. Abschließend und als letztes Element einer Anfrage folgen die Daten (body), welche man an den Server übermitteln möchte. Der body-Bereich ist nur relevant für die Operationen POST, PUT, PATCH oder DELETE.

Als Entwickler ist man aus zwei Perspektiven beteiligt. Clientseitig werden die bereitgestellten Services genutzt. Das Spektrum der unterstützenden Technologien ist hier nicht eingeschränkt, d. h. vom Desktop-Client über die Web-Applikation bis hin zur App für die mobilen Geräte sind alle Systeme denkbar. Nachfolgend betrachtet dieser Artikel jedoch die Möglichkeiten der Bereitstellung von Businesslogik als Service in Form eines universell über http-RESTful nutzbares API. Das Erstellen eines API hat mehrere Facetten:

• Inhaltlich geht es um die Umsetzung der Fachlogik, d. h. in welcher Form die Daten verarbeitet werden, u. a. ist zum Beispiel eine Datenbank über das API anzusprechen.
• API-Design: Hier muss man die Architektur des API festlegen. Es geht also darum, welche Aktionen der Server bei einer GET- bzw. PUT-Anforderung ausführen soll.
• Technische Umsetzung: Welche Programmiersprache und welches Framework kommen zum Einsatz. Hier hat man die Qual der Wal, d. h. es gibt unterschiedliche technische Herangehensweisen.

Im folgenden Abschnitt wird ein Lösungsansatz aufgezeigt, welcher eine effektive Möglichkeit darstellt, die Businesslogik in Form eines universellen API bereitzustellen. Zum Einsatz kommt der RAD Server aus dem Hause Embarcadero [2].

Betrachtet man sich die Architektur eines Anwendungssystems auf der Basis von RAD Server, so ergibt sich die Struktur gemäß Abb. 5.

Die Server-Applikation fungiert hier flexibel und wahlfrei als Backend oder Middleware und bietet folgende Features:

• Flexibel nutzbaren REST-Endpunkt: Clientseitig werden die Services als universelle REST/ JSON-API bereitgestellt und können damit nahezu von allen Arten von Clients (Desktop, Mobile, Web) genutzt werden. Eine integrierte Zugriffsteuerung erlaubt es, Berechtigungen für die API-Nutzung über Benutzerauthentifizierung festzulegen. Mit der integrierten API-Analyse bekommt man einen Überblick über die Nutzung der Services.
• Middleware: Serverseitig bietet der RAD Server vielfältige Möglichkeiten, u. a. die Integration von Unternehmensdatenbanken, die Verwaltung von IoT-Hardware und die Integration von Cloud- und BaaS-Diensten wie Google, Amazon, Facebook und Kinvey.
• Anwendungsdienste: Der RAD Server bietet ein Set an Anwendungsdiensten wie Benutzerverzeichnis- und Authentifizierungsdienste, Push-Benachrichtigungen, Indoor-/ Outdoor-Positionsermittlung und JSON-Datenspeicher.

Interessant ist der Blick in den Quellcode zur Definition unserer RESTful API MyService. Den gesamten Code hat RAD Studio generiert:

unit service;
// EMS Resource Unit
interface
uses
  System.SysUtils, System.Classes, System.JSON,
  EMS.Services, EMS.ResourceAPI,
  EMS.ResourceTypes;

type
  [ResourceName('MyService')]
  {$METHODINFO ON}
  TMyServiceResource = class
  published
    procedure Get(const AContext: TEndpointContext; const ARequest: TEndpointRequest; const AResponse: TEndpointResponse);
  end;
  {$METHODINFO OFF}

implementation
procedure TMyServiceResource.Get(const AContext: TEndpointContext; const ARequest: TEndpointRequest; const AResponse: TEndpointResponse);
begin
  // Sample code
  AResponse.Body.SetValue(TJSONString.Create('MyService'), True)
end;

procedure Register;
begin
  RegisterResource(TypeInfo(TMyServiceResource));
end;

initialization
  Register;
end.

Letztendlich entscheidend ist die Definition der Procedure Get (TMyServiceResource.Get), in welcher die Implementierung der http-Methode GET für die API stattfindet. Wir geben als Antwort hier lediglich einen JSON-Datenstrom mit einer einzigen Zeichenkette (MyService) zurück. An dieser Stelle müsste in Produktionsprojekten der Code hinterlegt werden, welcher bei Empfang einer GET-Message vom Client ausgeführt werden soll.

Dass die Ressource via REST von "außen" erreichbar ist, kann man wie folgt schnell testen. Starten Sie das aktive Projekt in RAD Studio und die Ressource wird über den Entwicklungsserver bereitgestellt. Wechseln Sie zum Internetbrowser und rufen Sie nun den Endpunkt mit localhost:8080/MyService auf (Abb. 15).

Andere http-Methoden (POST, Delete usw.) sind auf gleiche Art und Weise zu implementieren. Es genügt als Einstiegspunkt jeweils eine eigene Prozedur (procedure), in deren Rumpf der zu verarbeitende Code hinterlegt wird. Über vorgefertigte Bibliotheken ist es auf sehr einfache Art und Weise möglich, die zu sendenden Daten als allgemein üblichen JSON-Datenstrom zu übermitteln.

Die Nutzung des Developmentservers auf dem lokalen Rechner ist natürlich nur während der Entwicklung möglich. Für eine Produktionsumgebung sollten Sie den EMS-Server und den EMS-Konsolenserver auf einem Webserver einrichten. Aktuell werden Microsoft IIS Server (Windows) und Apache Server (Windows, Linux) unterstützt [5].

Wir haben also gesehen, dass es auf diese Weise möglich ist, schnell und effektiv Anwendungslogik als generisch nutzbaren Service in Form eines API auf einem Server zur Verfügung zu stellen.