Konferenz 2009/ROA
- Referent
- Arnulf Christl
Seit einiger Zeit spaltet eine sehr grundsätzliche Grundsatzdiskussion IT-Architekten in zwei Lager. Das eine Lager verfolgt das RPC-Konzept (Remote Procedure Call) der sogenannten Service-orientierten Architektur (SOA). Das andere Lager befürwortet Ressourcen-orientierte Architekturen (ROA), die dem REST-Prinzip folgen. Mit diesen zwei Architektur-Mustern werden jeweils auch zwei sehr unterschiedliche Technologien assoziiert, auf der Seite der RPC-Anwender wird SOAP favorisiert, im Lager der ROA werden RESTful-orientierte Dienste bevorzugt. In den INSPIRE Richtlinien wird (zur Zeit der Einreichung dieses Vortrags) auf SOAP-basierte Technologie verwiesen. Allerdings gibt es kaum Anwendungsbeispiele offener, produktiver SOA die unterschiedliche Technologien bedienen können, wie sie typischerweise in GDI angetroffen werden. Das Konzept der ROA hingegen ist vom Prinzip her offen und hat sich im größten produktiven Netzwerk, dem Internet selbst bewährt. Es fehlten jedoch theoretische Hintergründe, die ROA wurde eher als Phänomen wahrgenommen und beschrieben.
Das Architekturparadigma Representational State Transfer (REST) wurde bereits in der Dissertation Architectural Styles and the Design of Network-based Software Architectures von Roy Fielding beschrieben. RESTful orientierte Web-Dienste bewähren sich seit Jahren im praktischen Einsatz auch großer kommerzieller Anbieter wie Amazon und Google.
Grundlagen Ressourcen-orientierter Architektur-Muster Representational State Transfer (REST) ist ein Architektur Modell, welches beschreibt, wie das Internet funktioniert. Das Modell ist Anleitung und Referenz für Entwicklungen, die das volle Potential des Web nutzen. Vor allem für die Wiederverwendbarkeit, Interoperabilität, Robustheit, Skalierbarkeit und Stabilität sind die REST Architektur und RESTful Services besonders geeignet. REST ist kein Produkt oder Standard sondern beschreibt, wie Web Standards in einer Web-gerechten Weise einsetzt werden können. RESTful Web-Dienste nutzen das Applikationsprotokoll HTTP und die damit assoziierten klar definierten Methoden GET, PUT, POST und DELETE sowie die heute noch wenig genutzten HEADERS und OPTIONS.
- Die Grundidee des Architekturmodells ist eine klare Trennung zwischen Ressource (Service) und Anwendung. Es besteht keine dauerhafte Kommunikation bei der sich die Serverseite den Zustand der Anwendung merkt, sondern jede einzelne Abfrage ist für sich genommen eine abgeschlossene, stabile Aktion. Der Anwendungszustand ist unabhängig vom Zustand des Dienstes (der Dienst kennt die Anwendung nicht).
- Die Funktionalität einer Anwendung wird nicht in den Eigenschaften eines Dienst abgebildet, sondern in Ressourcen. Die Funktionen eines Dienstes werden in eigene adressierbare Ressourcen zerlegt.
- Jede Ressource hat eine eigene, eindeutige Adresse (im Internet eine URL bzw. eigentlich eine URI).
- Alle Ressourcen werden über die gleiche wohl geformte Schnittstelle (uniform interface) angesprochen. Der Zustand der Ressource und der Anwendung sind unabhängig. Die Anwendung erhält auf Anfragen immer einen klar definierten Rückgabewert.
- Ein klar definierten Satz von Methoden
- Ein klar definierten Satz von Datentypen
- Als Voraussetzung muss das Protokoll deshalb:
- Client-Server orientiert
- zustandslos (stateless)
- direkt adressierbar
- und unveränderlich (immutable) sein.
Am Beispiel der Open Source Software FeatureServer wird ein RESTful Service erläutert und vorgestellt.
Im Bereich der Geodatenverarbeitung und vor allem in weit vernetzten Systemen wie Geodateninfrastrukturen bieten RESTful Web Services Vorteile, vor allem auch was die Findbarkeit und Wiederverwendbarkeit von Diensten angeht. Die Grundlagen der Architektur, die mit INSPIRE angestrebt wird eignen sich hervorragend für diesen Architekturstil, die aktuellen Entwicklungen klammern diesen Aspekt jedoch noch weitgehend aus. Erst die Erfahrung mit lebenden Systemen wird zeigen, welche Vorteile sich durch den Einsatz von RESTful Web-Diensten ergeben und für welchen Einsatzzweck Architekturen Ressourcen-orientiert sein sollten.
RPC- oder Ressourcen-orientiert
Für beide Architekturmodelle gibt es geeignete Einsatzgebiete. Die unterschiedlichen Eigenschaften haben assoziierte Technologien hervorgebracht. In vielen Diskussionen wird vor allem wird zwischen SOAP und RESTful Services unterschieden, obwohl das eigentlich keinen Sinn macht, da ersteres eine Technologie und Standard und zweiteres ein Anwendungsmuster (Pattern) darstellt. Sowohl SOAP als auch RESTful orientierte Dienste werden bereits seit Jahren produktiv eingesetzt, teilweise auch mit Überschneidungen. Beide Architekturmuster haben jeweils ihre Berechtigung, welche Technologie am sinnvollsten zum Einsatz kommt kann daher gut abgewogen werden.
- Kontakt zum Autor
- Arnulf Christl
- WhereGroup GmbH Co. KG
- Siemensstr. 8
- +49 (0)228 909038-23
- arnulf.christl@wheregroup.com
Eine Liste mit weiterführenden Verweisen und ein Buchtipp laden zur Vertiefung des Themas ein.
