Nachdem Peter Bucher und ich vor rund vier Wochen unser erstes Streitgespräch unter dem Titel Dynamic Language Runtime: .NET, quo vadis? veröffentlicht haben, haben wir für dieses Mal ein Thema ausgewählt, das in der IT durchaus für Furore sorgt:
SOA vs WOA
Die erste Herausforderung im Hinblick auf diese Begriffe ist, sie überhaupt zu definieren. Ich für meinen Teil kann es mir diesbezüglich verhältnismäßig leicht machen, da sich in der aktuellen Ausgabe der dotnetpro ein Artikel von mir findet, der sich mit genau dieser Frage beschäftigt. Daher werde ich im folgenden darauf Bezug nehmen. Allerdings bin ich auf die Definition von Peter gespannt, die sich zeitgleich in seinem Blog findet. Folgend nun mein Kommentar zu diesem Thema:
Der Terminus SOA (serviceorientierte Architektur) geht auf das Marktforschungsunternehmen Gartner zurück, das ihn erstmals 1996 verwendete. Obwohl Gartner die Möglichkeit gehabt hätte, den Begriff mit einer Definition zu hinterlegen, hat das Unternehmen diese Herausforderung anderen überlassen.
Durchsucht man das Web, so stößt man - je nachdem, wen man fragt - auf unterschiedliche Definitionen. Laut Wikipedia wird jedoch häufig die Definition von OASIS zitiert, die SOA als "ein Paradigma für die Strukturierung und Nutzung verteilter Funktionalität, die von unterschiedlichen Benutzern verantwortet wird" beschreibt.
Offensichtlich geht es bei SOA also um das Vernetzen von Diensten verschiedener Anbieter. Die naheliegende Frage ist dabei, was dabei unter einem Dienst zu verstehen ist. Prinzipiell ist ein Dienst mit einer Komponente vergleichbar, denn für beide gelten:
- Ein Dienst verfügt über eine wohldefinierte Schnittstelle, die zur Kommunikation mit diesem genutzt wird. Der Dienst fungiert dabei als Blackbox, die Implementierung bleibt für die den Dienst nutzende Anwendung also verborgen.
- Ein Dienst steht prinzipiell allen Anwendungen zur Verfügung, potenziell auch über ein lokales Netzwerk oder das Internet. Anwendungen müssen in diesem Fall mit Latenz und potenziell auch mit Nichtverfügbarkeit umgehen können.
Anders als eine Komponente wird ein Dienst jedoch autonom ausgeführt - das heißt, er wird nicht im Kontext einer Anwendung ausgeführt, sondern unabhängig von dieser. Man könnte sagen, ein Dienst ist eine ausgelagerte, eigenständig ausführbare Komponente.
Auf dieser Basis ist es bereits sehr einfach, den Begriff SOA anschaulich zu erklären: Eine serviceorientierte Architektur ist ein Ansatz für die Architektur einer Anwendung, bei der die Funktionalität nicht ausschließlich innerhalb einer Anwendung positioniert wird, sondern auf die Anwendung und entsprechende Dienste verteilt wird.
Eine ausgesprochen wichtige Frage für SOA ist, wie die einzelnen Dienste oder die Anwendung und die Dienste miteinander kommunizieren. Hierzu gibt es zahlreiche Möglichkeiten. Prinzipiell ist jede asynchrone, streambasierte Kommunikation denkbar. Häufig wird SOA mit Webservices gleichgesetzt, allerdings sind Webservices nach den WS*-Standards nur eine von vielen möglichen Implementierungen von SOA.
Ebenfalls wird dabei deutlich, dass es sich bei SOA nicht um eine Blaupause für eine Architektur handelt, sondern lediglich um einen Denkansatz - ein Paradigma eben -, das für jede Anwendung in ihrem Kontext neu zu überdenken und auszuarbeiten ist.
Im vergangenen Jahr hat sich ein weiterer Begriff aus dem Hause Gartner verbreitet: WOA (weborientierte Architektur). Die Namensähnlichkeit von WOA zu SOA ist mit Sicherheit kein Zufall, und tatsächlich hängen beide Begriffe auch eng zusammen: Obwohl SOA nur eine abstrakte Idee, ein Paradigma einer Architektur beschreibt, wird es in der Praxis häufig synonym mit Webservices und den entsprechenden WS*-Standards verwendet.
Prinzipiell ist daran auf den ersten Blick nichts auszusetzen, schließlich bieten Webservices eine äußerst flexible Plattform für serviceorientierte Architekturen. Trotzdem gibt es einige Punkte, an denen auf Webservices basierende Architekturen mit Problemen zu kämpfen haben:
- Zum einen erfordert die Arbeit mit ihnen sehr gute Kenntnisse von zahlreichen Standards. Obwohl im Bereich der Webtechnologien
bereits seit Jahren entsprechende etablierte Technologien existieren, gibt es für Webservices häufig eine eigene Variante. Dies erhöht den Einarbeitungsaufwand und erschwert die Migration.
- Zum anderen ist das SOAP-Protokoll, das den Webservices zugrunde liegt, verhältnismäßig ausladend. Selbst das Übertragen einer kleinen Nachricht erfordert eine umfangreiche XML-Struktur, sodass die Kommunikation häufig ein wenig schwerfällig wird und schlecht skaliert.
Als Ausweg bietet sich der Einsatz der bereits seit Jahren etablierten Webstandards an, um auf deren Grundlage einfach formulierte XML-Nachrichten zu versenden. Genau dieses Ansinnen befriedigt REST. Dessen Ansatz verfolgt die gleichen Ziele wie die WS*-Standards, ist aber deutlich einfacher aufgebaut. Als wesentliche Technologien liegen REST das HTTP-Protokoll, URLs und XML zugrunde - also einfache, erprobte Technologien, die zahlreichen Webentwicklern bereits geläufig sind.
Da REST in den vergangenen Jahren zunehmend an Bedeutung gewonnen hat und zahlreiche Webservices inzwischen auch parallel als REST-Service zur Verfügung stehen, steht dem Aufbau einer WOA-basierten Anwendung mit den dazugehörigen Diensten nichts im Wege.
WOA ist also eine auf das Web optimierte und auf REST basierende konkrete Version von SOA, und somit lediglich eine mögliche Ausprägung einer serviceorientierten Architektur, ebenso wie Webservices eine solche mögliche Ausprägung darstellen.