Dieser Artikel soll einen Einblick in Serviceorientierte Architekturen geben, im Volksmund auch bekannt als „SOA“. Es gibt nicht die SOA und es gibt auch nicht das Tool für SOA oder die Vorgehensweise bei der Einführung einer SOA sondern nur mögliche Deutungen und mögliche Pfade, wie man eine SOA umsetzen, bzw. einführen könnte. Die in diesem Artikel beschriebenen Ansätze folgen zu einem großen Teil dem deutschsprachigen Standardwerk zu Service-orientierten Architekturen, Service-orientierte Architekturen mit Web Services: Konzepte – Standards – Praxis von Ingo Melzer. Es sei darauf hingewiesen, daß die besprochenen Konzepte selbstverständlich auch auf andere Programmiersprachen anwendbar sind. Einzig die Tools sind umgebungsspezifisch zu wählen.

Definition

Beginnen wir erst einmal mit der Begriffsdefinition und schauen mal, was die deutsche Wikipedia zu dem Thema sagt:

Serviceorientierte Architektur (SOA), engl. service oriented architecture, auch dienstorientierte Architektur, ist ein Ansatz der Informationstechnik, Dienste von Mitarbeitern und Organisationen zu strukturieren und zu nutzen. Diese Strukturierung und Nutzung kann auf unterschiedlichen Ebenen erfolgen. […]

Die englische Wikipedia beschreibt SOA als:

Service Oriented Architecture (SOA) is a computer systems architectural style for creating and using business processes, packaged as services, throughout their lifecycle. SOA also defines and provisions the IT infrastructure to allow different applications to exchange data and participate in business processes. These functions are loosely coupled with the operating systems and programming languages underlying the applications. […]

Im Klartext?

Vereinfachen wir dieses Businesskauderwelsch so kommen wir zu folgenden Aussagen: in einer SOA werden Funktionen (z.B. „Kontostand des Kunden XY abfragen“, „Warenbestand für Artikel Z um eins erhöhen“) und komplette Businessprozesse (z.B. „Kundenkonto verwalten“, „Wareneingang prüfen“) dergestalt standardisiert, daß sie unternehmensweit zugänglich sind. So kann es allen Abteilungen der Unternehmens-IT ermöglicht werden, Funktionen zu nutzen, die vormals nur anderen Abteilungen zugänglich waren.

Mit der Einführung einer SOA wurde diese Architektur optimiert. Abteilung A hat seine Software in C++ als Desktopanwendung entwickeln lassen, während Abteilung B eine webbasierte Java-Lösung hat, damit auch Lieferanten Zugriff gewährt werden kann. Beide nutzen eine SOA-basierte Anwendungsschicht, über die die ihnen zugeordneten Funktionen und Prozesse zugreifbar sind. Folgend eine schöne Visualisierung von Sun Microsystems für Architekturen mit und ohne SOA:

Kalter Kaffee?

Fällt Ihnen etwas auf?
Diesem Prinzip folgen Softwareentwickler eigentlich schon seit Jahrzehnten, soweit sie Software vorausschauend entwickeln. Es haben sich dabei Unternehmensframeworks herausgebildet, die allerdings oftmals auf eine bestimmte Programmiersprache festgelegt sind. Diese Unternehmensframeworks werden dann von allen Abteilungen genutzt, die unternehmensspezifische Funktionen aufrufen müssen.
Beispiel: ein Fahrzeug-Leasingunternehmen könnte seinen Rechenkern mit seinen unternehmensspezifischen Algorithmen in einer Java-Library implementiert haben, die die Abteilungen anschließend in ihre Java-Anwendungen einbinden. Ein Zugriff auf diesen Rechenkern aus einer C++-Anwendung oder einer Ruby on Rails-basierten Weboberfläche ist aber nur über Verrenkungen möglich. Um diesen Problemen entgegenzuwirken hat sich über die Jahre jedes Unternehmen mehr oder weniger sein eigenes Süppchen gekocht und beispielsweise Funktionszugriffe über proprietäre XML-Nachrichten implementiert, ganze Prozesse in Datenbankprozeduren ausgelagert oder gleich RFC und CORBA eingesetzt.

Das zugrundeliegende Problem, ein höheres Abstraktionsniveau, konnte damit allerdings nicht erreicht werden.

SOA vereinheitlichen altbekanntes

SOA sind also, u.a., die Vereinheitlichung und Kodifizierung dieser Problematik in eine Sprache, Definition und Vorgehensschema. Es verhält sich damit ähnlich wie Design Patterns zu Problemstellungen der Softwareentwicklung: es wird eine gemeinsame Sprache und ein bestimmtes Vorgehen gefunden, die konkrete Umsetzung dessen wird allerdings einer beliebigen Implementierung überlassen.
Beispiel: das MVC-Design Pattern ist per UML definiert, seine konkrete Umsetzung aber der genutzten Programmiersprache mit seinen spezifischen Möglichkeiten überlassen. In der SOA ist die Zielsetzung und das Vorgehen definiert, seine Umsetzung aber der Technologie der Wahl überlassen. Hier kommen dann Technologien wie WebServices zum Zuge, die sich für die Umsetzung solch serviceorientierter Architekturen etabliert haben.

Historie

Wir tun den SOA allerdings unrecht, wenn wir sie auf die genannten Punkte reduzieren und damit implizit abwerten würden. SOA sind nicht nur eine reine Kodifizierung eines Vorgehensmodells, sondern es handelt sich bei ihnen auch um eine logische Weiterentwicklung von Softwareentwicklungsmethodiken die den Anforderungen der Komplexität heutiger Software gerecht wird. Aus der Vergangenheit kennen wir das Entstehen prozeduraler Sprachen, die uns vom Spaghetti-Code mit seinen GOTO-Befehlen befreit haben. Wiederkehrende Prozesse wurden, je nach Programmiersprache, in Funktionen, Prozeduren oder Methoden gekapselt. Programmcode wurde in verschiedene Dateien aufgeteilt, die der wachsenden Komplexität der Software entgegentreten sollten. Diese Komplexität stieg allerdings weiter an und es entstand die objektorientierte Programmierung, die uns seit ca. 20 Jahre lang treu zur Seite stehen. Im Zuge der Entwicklung der OOP wurden auch die Vorteile komponentenbasierter Softwareentwicklung erkannt, die den Grad der Wiederverwendung entwickelter Softwareartefakte noch einmal erhöht haben.
Beobachtet man diese Entwicklung, so stellt man fest, daß mit jedem Schritt das Abstraktionsniveau erhöht wurde und die SOA den nächsten logischen Schritt auf diesem Weg darstellen.

Komponenten einer SOA

Wie wir gelernt haben, ist eine Eigenschaft einer SOA die Abstraktion von Unternehmensprozessen in wiederverwendbare Services. SOA definiert in diesem Zusammenhang drei Rollen, die sich in dem folgenden Diagramm finden:

Es finden sich folgende Rollen, die elementare Bestandteile einer SOA ausmachen.

• Der Verzeichnisdienst veröffentlicht die von Dienstanbietern bekanntgemachten Services und beantwortet Anfragen von Dienstnutzern nach diesen Services mit einer Referenz auf die bei dem entsprechenden Dienstanbieter installierte Instanz.
• Der Dienstanbieter bietet Services an, die von Dienstnutzern verwendet werden können. Damit diese Services gefunden werden können werden sie vom Dienstanbieter zentral bei einem oder mehreren Verzeichnisdiensten bekannt gemacht.
• Der Dienstnutzer sucht einen bestimmten Service beim Verzeichnisdienst und erhält eine Referenz, welcher Dienstanbieter einen solchen Service anbietet. Anschließend findet eine Bindung beim passenden Dienstanbieter statt und der Dienst kann genutzt werden.

In Kürze lässt sich der Prozess damit folgendermaßen darstellen:

1. Ein Dienstanbieter veröffentlicht einen angeboten Service beim Verzeichnisdienst.
2. Ein Dienstnutzer sucht beim Verzeichnisdienst nach einem passenden Service und erhält eine Referenz auf den Dienstanbieter zurück.
3. Der Dienstnutzer führt eine Bindung mit dem Dienstanbieter durch und nutzt den gewünschten Service.

Enterprise Service Bus

Ein weitere elementare Komponente einer SOA ist der Enterprise Service Bus (ESB). Wenn Sie sich umhören werden fünf Experten zehn Meinungen darüber haben, ob und wie ein ESB Bestandteil einer SOA ist. Wir möchten ihn allerdings als Teil einer SOA verstehen, vor allen Dingen, da sie in der Fachliteratur fast ausschließlich immer in einem Atemzug genannt werden.

Für das Verständnis eines ESB möchten wir seine Funktion mit der einer nachrichtenorientierten Middleware (Message-oriented Middleware, MOM) vergleichen. Als Beispiel sei IBM’s WebSphere MQ genannt, ein JMS -kompatibler Messagingserver, der es uns ermöglicht, über Queues und Topics Nachrichten mit entfernten Systemen auszutauschen. Ein ESB hat allerdings den Vorteil, daß die Kommunikation nicht kreuz und quer durch die Systeme läuft, weil sich, wie bei der MOM, jeder Service mit n anderen Diensten verbindet. Stattdessen verbindet sich jeder interessierte Service mit dem ESB, der über ein intelligentes Routing und Transformationen der Nachrichten dafür sorgt, daß angemeldete und berechtigte Services die Nachrichten erhalten die sie benötigen. Visualisiert stellt sich das folgendermaßen dar:

Etablierte Technologien

SOA haben eine Reihe von Technologien hervorgebracht, bzw. „großgemacht“, die sich als Quasi-Standards für die Umsetzung einer SOA durchgesetzt haben. Folgende Begrifflichkeiten sollten daher geläufig sein:

• Verzeichnisdienste nutzen UDDI als zugrundeliegende Technologie.
• Dienstanbieter stellen ihre Services als WebServices bereit.
• Dienstnutzer binden Services von Dienstanbietern zumeist per SOAP an.

Ein näherer Blick auf diese Technologien findet sich in weiteren Artikel auf dieser Website, für’s erste belassen wir es bei dieser Einführung.

SOA und das Unternehmen

Die Einführung einer SOA beginnt allerdings schon viel früher, und zwar auf Unternehmensebene und Geschäftsprozessebene. Diese Rahmenbedingungen haben wir in diesem Artikel ausgeklammert und haben uns mehr auf die technischen Aspekte konzentriert. Wer sich für diese Themen interessiert, sei auf die die folgenden Literaturempfehlungen hingewiesen.

Weiterführende Literatur

Das meiner Meinung nach einzige lesenswerte Buch zu Service-orientierten Architekturen (SOA) nennt sich Service-orientierte Architekturen mit Web Services: Konzepte – Standards – Praxis von Ingo Melzer und deckt alle wichtigen Themengebiete ab. Das Buch ist sehr verständlich geschrieben und auf dem aktuellen Stand und findet sich häufig auf Empfehlungslisten von Experten und diversen Fachmagazinen. Ich kann es uneingeschränkt empfehlen und bezeichne es gerne als deutschsprachiges Standardwerk zu Service-orientierten Architekturen und WebServices.

Weitere Empfehlungen: