Download (5Mb) - oops/ - Oldenburger Online-Publikations-Server

58 Entwurf
Dienste geteilt. Für die Kommunikation zwischen der Anwendung und den Services oder zwischen
den einzelnen Services werden Standard-Schnittstellen wie z.B. REST eingesetzt.
Bezüglich der von den Diensten bereitgestellten Schnittstelle wird im Fall dieser Architektur eine
Schnittstelle definiert, die die grundlegenden REST Methoden enthält, die von jedem Dienst bereitgestellt
werden müssen (siehe auch 7.3.5). Darüber hinaus definiert jeder Dienst eine eigene erweiterte
Schnittstelle, um die eigene Funktionalität bereitzustellen.
Die verfügbaren Dienste können in einem “Repository” oder “Gateway” gelagert werden und mittels
einem Web Server nach außen zu den Clients bereitgestellt. Ein Vorteil einer SOA-ähnliche Lösung
ist, dass die Dienste individuell auf verschiedenen Systeme gelagert werden können, um z.B.
eine bessere Fehlertoleranz zu erzielen. Im Rahmen des Architektur-Konzeptes dieser Arbeit werden
die Dienste in einem Gateway zusammengepackt und mithilfe eines hochperformanten Servers zur
Verfügung gestellt, wie im Detail im Laufe des Abschnittes 7.3.5 dargestellt wird.
Weiterhin wird zwischen “normale”, nicht-Echtzeit fähige Dienste und Echtzeit-fähige Dienste
unterschieden, indem die dafür zuständige Komponente für die Zwischenspeicherung oder Persistierung
(siehe auch vorheriger Paragraph) unterschiedlich ist. Während sich ein NonRealtimeService
mit der relationalen Datenbank in Verbindung setzen kann, spricht hingegen ein RealtimeService die
Echtzeit-Datenbank an. Ein weiterer Unterschied zwischen den zwei Arten einbezogener Diensten
wäre, dass die deklarierten Schnittstellen unterschiedlich sind. Des Weiteren verwenden beide Arten
von Diensten eigene “Unterkomponenten”, die die verschiedenen Persistenz-bezogene Programmlogik
einkapseln.
Ein weiterer Aspekt bezüglich der Bereitstellung von REST Web Services, nämlich die Entdeckung
vorhandener Dienste, wird im darauffolgenden Abschnitt behandelt.
Entdeckung und Beschreibung vorhandener REST Web Services
In [KTP11] wird die Idee eingeführt, dynamisch eine maschinenlesbare Darstellung vorhandener
RESTful Services zu erzeugen. Dies würde dazu dienen, einen einheitlichen und standardisierten
(REST-basiert) Datenaustausch mit den aufgelisteten Services zu ermöglichen. Ein Hilfsmittel für
diese Darstellung wird von der vorgeschlagenen WADL 1 Spezifikation repräsentiert. WADL (Web
Application Description Language) ist eine Sprache zur Beschreibung von Web Anwendungen, die
im Jahr 2009 zwecks Standardisierung bei W3C vorgeschlagen worden ist. Jedoch ist WADL noch
nicht standardisiert.
WADL ist ein XML-basiertes Dateiformat, das eine Plattform- und Programmiersprache-unabhängige
Beschreibung von HTTP-basierten Web Anwendungen anbietet. Eine verbreitete Perspektive von
WADL schildert dies als das RESTful Äquivalent von WSDL [KTP11]. Obgleich die Beschreibung
von REST-basierten Web Services möglich 2 ist, stellt sie sich als eine zu schwerfällige Annäherung
dar.
In dieser Arbeit wurden die Prinzipien von WADL in einer “verkürzten” Form übertragen: mithilfe
des häufig übersehenen HTTP Verbs namens OPTIONS und die benutzten Methoden zur Beschrei-
1
http://wadl.java.net/
2
Artikel von IBM: https://www.ibm.com/developerworks/webservices/library/wsrestwsdl/