Derzeit ist die IT-Anwendungsentwicklung und der Betrieb von IT-Applikationen geprägt von monolithischen, siloartigen Systemlandschaften. Die beträchtlichen Investitionen in Wartung, Pflege und Betrieb der historisch gewachsenen Systeme nehmen mittlerweile bis zu 70 Prozent des IT-Budgets in Anspruch.
Langfristig hat diese statische, teure IT kaum Zukunftschancen. Ein mögliches alternatives Konzept für eine dynamische, kostensenkende IT ist die serviceorientierte Architektur (SOA). SOAs sind ganz allgemein dadurch gekennzeichnet, dass sie die Flexibilität der IT erhöhen und somit die Kosten für Wartung, Pflege und Anpassung der IT an neue Anforderungen verringern.
Viele Unternehmen beginnen zurzeit damit, ihre IT auf serviceorientierte Architekturen umzustellen. Sie haben den Hauptnutzen der deutlich höheren Flexibilität erkannt und versuchen, ihn für eigene Zwecke umzusetzen.
SOAs punkten jedoch noch mit weiteren Features. Durch die Kapselung von IT-Funktionen in voneinander unabhängigen Diensten lassen sich die Auswirkungen von Änderungen beispielsweise signifikant beschränken.
Darüber hinaus können Dienste in unterschiedlichen Anwendungskontexten wieder verwendet werden. Neue Dienste und Produkte können so schneller eingeführt und existierende Dienste schneller an neue Anforderungen angepasst werden. Kosten und Entwicklungszeiten sinken. Diese Flexibilität kann auch genutzt werden, wenn neue regulatorische Rahmenbedingungen erfüllt werden müssen.
SOAs – Merkmale im Überblick
Serviceorientierte Architekturen lassen sich nur schwer fassen. Dies liegt daran, dass eine SOA keine konkrete Technik ist, sondern vielmehr eine abstrakte Software-Architektur. Im Zentrum steht das Anbieten, Suchen und Nutzen von Diensten über ein Netzwerk. Die Dienste werden dabei fast immer von Applikationen oder anderen Diensten genutzt. Welche Hardware, welche Software oder welches Betriebssystem dabei verwendet wird ist unerheblich.
Vom Standpunkt der Architektur aus betrachtet stellt eine SOA einen vollständigen Paradigmenwechsel in der IT dar: nicht mehr die Applikationen stehen im Vordergrund, sondern die Geschäftsprozesse. Wesentliches Merkmal einer SOA ist somit die Unabhängigkeit von den Details der Implementierung. Dienste sind lediglich „lose verkoppelt“. Damit ist gemeint, dass Dienste bei Bedarf dynamisch von Applikationen oder anderen Diensten gesucht und eingebunden werden. Dabei erfolgt die Einbindung zur Laufzeit. Oft ist zum Zeitpunkt der Übersetzung des Programms nicht bekannt, was zur Laufzeit aufgerufen wird.
Damit die Dienste gefunden werden können, gibt es einen Verzeichnisdienst oder ein Repository, in dem die Dienste registriert sind. Um die Dienste zu suchen und vor allem zu nutzen, muss der Aufrufer sich mit diesen unterhalten können. Dies geht nur über maschinenlesbare Schnittstellen, die offenen Standards genügen. Es muss also eine so genannte „Service Description“ in maschinenlesbarer Form vorliegen. Zulässig sind dann nur Zugriffe über diese Schnittstelle.
In jedem Fall erfolgt die Kommunikation innerhalb einer SOA vollständig automatisiert. Ein Mensch kann sie zwar anstoßen, die Bearbeitung geschieht aber unabhängig von ihm und automatisch.
Ein Beispiel für einen SOA-gesteuerten Prozess ist die automatische Überweisung eines Geldbetrages, sobald der Kontostand des Zielkontos unter einem bestimmten Betrag fällt. Solche Architekturen werden auch als ereignisgesteuert bezeichnet.
Grundsätzlich gibt es in einer SOA drei Beteiligte: Den Anbieter des Dienstes, den Nutzer und den Vermittler. Die Grafik zeigt das Zusammenspiel der drei Akteure – das „magische SOA-Dreieck“. Die drei Elemente werden in den folgenden Abschnitten ausführlicher beschrieben.
SOA-Dienste
Wie kann man sich einen SOA-Dienst konkret vorstellen? Im einfachsten Fall lässt sich ein Dienst als Weiterentwicklung von PlugIns auffassen. PlugIns haben ebenfalls eine eindeutige Schnittstelle und eine für den Anwender unsichtbare Implementierung. Sie erweitern die Anwendung um bestimmte Funktionen, die bei der Programmerstellung noch nicht geplant waren.
Anders als bei SOA-Diensten liegen bei PlugIns die Schnittstellen aber meist nicht in maschinenlesbarer Form vor und sie nutzen meist nur eine einzige, sehr starre Schnittstelle. Bei SOA ist das anders. Im Zusammenhang mit Web Services hat sich bei SOA die Web Service Description Language (WSDL) als Beschreibungssprache für solche Schnittstellen durchgesetzt und SOAP als Standard für Nachrichten.
Obgleich WSDL und SOAP an unterschiedliche Transportmechanismen gebunden werden können, werden sie häufig mit synchroner Kommunikation über HTTP assoziiert: ein Client schickt einen Request an einen Server und erhält ein Reply zurück. In vielen Kontexten ist aber eine asynchrone Kommunikation über Messages und Queues vorteilhafter – aus diesem Grund hat sich auch MOM (Message Oriented Middleware) als ein Integrationsparadigma etabliert. Bei asynchroner Kommunikation dominiert inzwischen JMS (Java Message Service).
Viele SOA-Plattformen unterstützen ein breites Spektrum an Austauschformaten, so dass Anwender im Einzelfall entscheiden können, welches Format für den jeweiligen Anwendungsfall am geeignetsten ist. Der Enterprise Service Bus fungiert dann als Bindeglied und Kommunikationsinfrastruktur.
Wird eine SOA-Plattform zur Verfügung gestellt, muss diese konkret betrieben und gewartet werden. Der Diensteanbieter muss die Verfügbarkeit garantieren. Dazu gehören oft Aufgaben, die in der Regel in Rechenzentren geleistet werden wie Datensicherung oder Wartung.
Sicherheit ist ebenfalls ein Punkt, den der Servicebetreiber abdecken muss. Dazu gehören Aufgaben wie Authentifizierung und Authentisierung. Bei der Authentifizierung prüft der Diensteanbieter, ob der Aufrufer auch derjenige ist, der er zu sein behauptet. Die Authentisierung stellt sicher, dass der Aufrufer auch berechtigt ist, die Funktionalität zu nutzen, die er gerade aufruft.
Die beschriebenen Aufgaben gelten für alle Dienste – auch für diejenigen, die der Diensteanbieter gar nicht selbst anbietet, sondern etwa über das Netz nutzt.
Dienstverzeichnis und -nutzer
Dienste müssen verzeichnet werden, um von einem potenziellen Nutzer gefunden zu werden. Bei der Entwicklung neuer Anwendungen kann dann einfach festgestellt werden, welche Dienste bereits vorhanden sind und genutzt werden können.
Hierzu dient ein Dienstverzeichnis, auch Registry oder Repository genannt. In einer einfachen SOA muss jeder Anbieter selbst aktiv seine Dienste bei einem solchen Verzeichnis registrieren. Künftig könnten solche Aufgaben auch Suchmaschinen erledigen.
Mit UDDI (Universal Description, Discovery and Integration) existiert bereits seit Jahren ein Registry-Standard, der aber bisher nur sehr vereinzelt in der Praxis eingesetzt wird. Viele Unternehmen verwenden stattdessen ein selbst entwickeltes Repository für die zentrale Bereitstellung von Informationen über Dienste.
Die Güte eines Verzeichnisses steht und fällt mit den Kategorien. Für eine gute Klassifizierung ist es nötig, dass jeder Dienst genau einer Kategorie eindeutig zugeordnet ist. Damit die SOA akzeptiert wird und möglichst einfach gehandelt werden kann, sollte die Suche nach Diensten für einen Nutzer von einem normalen Diensteaufruf nicht zu unterscheiden sein.
Praktisch wird es bei den Diensten keine Monopole geben, sondern eine Vielzahl von Dienste-Verzeichnissen. Viele Firmen werden mindestens eine Instanz für ihre Internet-Angebote haben und eventuell eine zweite für den internen Zugriff. Ferner kann es weitere Installationen für einzelne Bereiche geben.
Der Dienstenutzer muss dem Diensteanbieter nicht bekannt sein. Für ihn ist es wichtig, dass Standards vorhanden sind und vor allem auch eingehalten werden. So muss der Dienst fähig sein, dem Nutzer seine Schnittstelle vollständig darzulegen. Danach findet die Kommunikation über ein Protokoll statt, das beiden bekannt sein muss. Ein Beispiel für ein solches Protokoll ist SOAP.
Ausführbare Aktionen
Das Zusammenspiel zwischen Dienstanbietern, Dienstnutzern und Dienstverzeichnis muss gut funktionieren. Denn eine ganze Reihe von Aktionen können in einer solchen Umgebung ausgeführt werden.
Eine erste solche Aktion ist die „Veröffentlichung“ eines Dienstes. Der Eintrag und die Anmeldung in einer Registry reichen hierfür nicht aus. Der Dienst muss vorher in einer entsprechenden Umgebung installiert werden – ein Vorgang, der als „Deployment“ bezeichnet wird. Erst anschließend sollte der Dienst registriert werden.
Die zweite Aktion ist die des „Suchens“ nach Diensten. Die Frage stellt sich, wie man nach einem Dienste suchen kann. Bei Diensten gibt es keine guten Quellen, die eine Suchmaschine analog etwa zu Websites durchsuchen kann.
Wichtig ist daher, dass für jeden Dienst eine gute Beschreibung erstellt wird. Dies wird meist auf Basis von Taxonomien oder Ontologien vorgenommen. Vereinfacht kann man sich ein solches Verzeichnis wie die Gelben Seiten vorstellen – für verschiedene Kategorien gibt es eine Liste von möglichen Diensten.
Ist der Dienst gefunden, so ist eine weitere Aktion möglich: Die Aushandlung, wie mit dem Dienst zu interagieren ist. Dazu wird zunächst die Schnittstellenbeschreibung des Dienstes abgefragt. Unter Umständen ist der Dienst nur unter bestimmten Voraussetzungen nutzbar – etwa der eines Zertifikats oder der Authentifizierung. Dazu müssen entsprechende Richtlinien ausgetauscht werden. Erfolgt eine Einigung, so spricht von einer erfolgreichen „Bindung“ an einen Dienst.
SOA – ein neues „Programmierkonzept“
In mancherlei Hinsicht erinnert SOA an entfernte Funktionsaufrufe, so genannte Remote Procedure Calls (RPCs). Zwar werden Web Services, eine der Umsetzungen von SOA, oft als einfache RPCs verwendet. Die Nutzung des SOA-Konzepts geht aber wesentlich weiter und ist das derzeit letzte Glied in einer Reihe von Programmierkonzepten. Zur Erinnerung und zum Verständnis von SOA ein paar wichtige Pfeiler moderner Programmierkonzepte.
Die prozedurale Programmierung wurde entwickelt, um dem schlecht wartbaren Spaghetti-Code aus den Anfängen der Software-Entwicklung Herr zu werden. Dazu wurde das Modulkonzept eingeführt, das die Verteilung eines Programms auf mehrere Dateien und damit eine übersichtliche Strukturierung und die Erstellung von Bibliotheken ermöglichte. Mit der prozeduralen Programmierung wurde es vor allem aber möglich, einzelne Funktionalitäten zu kapseln und an beliebigen Programmstellen durch einen Aufruf zu nutzen.
Als Nachfolger der prozeduralen Programmierung entstand Mitte der 80er Jahre die objektorientierte Programmierung – Folge der stetig zunehmenden Komplexität der Programmentwicklung. Die objektorientierte Programmierung erlaubte eine deutlich bessere Strukturierung und eine brauchbare Wiederverwendung.
Doch auch die objektorientierte Programmierung war nicht der Weisheit letzter Schluss. Objekte sind in vielen Fällen zu feingranular und schränken die verwendete Sprache und Umgebung sehr stark ein. Den nächsten Schritt bildeten deshalb die serviceorientierten Architekturen.
SOA-Anwendungen
Bei der Einführung einer SOA hat sich ein schrittweises Vorgehen bewährt, bei der Abteilungen und Anwendungen nach und nach auf die SOA umgestellt werden. Dies verringert den organisatorischen Aufwand und vermindert das Risiko des Scheiterns.
Besonders geeignet für initiale SOA-Projekte sind
-
Anwendungen, für die Abteilungen zuständig sind, die der SOA-Idee positiv und aufgeschlossen gegenüber stehen;
-
die vergleichsweise einfach zu realisieren bzw. auf SOA umzustellen sind, also mit wenig Risiko verbunden sind;
-
die eine hohe Sichtbarkeit garantieren, z.B. weil sie von vielen anderen Abteilungen genutzt werden oder eine für das Unternehmen zentrale Funktionalität bereitstellen.
Die Entwicklung einer SOA-Anwendung läuft typischerweise folgendermaßen ab: Als erstes werden typische Szenarien festgelegt und in Form von Fallstudien festgehalten. Diese werden als Ablaufdiagramm modelliert. Dabei werden die Prozesse, die in den typischen Anwendungsfällen ablaufen, festgehalten und präzisiert. Im dritten Schritt werden dann die einzelnen Prozessschritte genauer herausgearbeitet. Diese einzelnen Komponenten sind die Dienste oder Services, die an externe Partner vergeben werden können.
Ein Wort noch zu SOA und ASP: SOA hat einiges mit ASP-Anwendungen gemein, unterscheidet sich davon jedoch auch. Bei ASP liegt die ganze Anwendung bei einem Anbieter und kann extern von einem Nutzer aufgerufen werden. Anders als bei SOA ist es bei ASP aber immer eine ganze Anwendung, während bei SOA Teile aufgerufen werden.
Ein Beispiel ist eine Office-Anwendung. Nutzt man einen Editor kann man bestimmte Zusatz-Funktionalitäten verwenden, die der Editor selbst nicht anbietet. Beispielsweise eine Rechtschreibkontrolle, Zeichenformatierung oder Import- und Export-Filter. Wird beispielsweise die Rechtschreibkontrolle aufgerufen, so wird nach dem obigen Schema in einem Verzeichnis nach einem solchen gesucht, diese gefunden und genutzt. Was im Hintergrund abläuft, merkt der Nutzer nicht.
Langfristig könnten SOA-Anwendungen das Ende der heutigen Applikationen sein, wobei entsprechenden Abrechnungsmodelle installiert werden müssten. Statt monolithischer Anwendungen dürften in jedem Fall in Zukunft mehr komponentenbasierte Systeme entstehen.
Enterprise Service Bus
Eine zentrale Rolle im SOA-Konzept nimmt der Enterprise Service Bus (ESB) ein, wobei zwei Interpretationen üblich sind. Ein Teil der Experten interpretiert ESB als Bestandteil einer SOA. Nach dieser Interpretation wird die Kommunikation in der SOA über eine zentrale Komponente mit intelligenten Routing-Fähigkeiten vorgenommen. Dieser Verteiler wird dann als ESB bezeichnet.
Danach ist die zentrale Aufgabe eines ESB der Austausch von Daten zwischen IT-Systemen oder Teilen von IT-Systemen. Der Datenaustausch findet dabei in Form von Service-Aufrufen statt. Der ESB kann als zentraler Server existieren („Hub-and-Spoke-Ansatz“), als vollständig dezentrale Umsetzung oder auch als föderiertes System, das heißt als Verbindung mehrerer Zentralsysteme. Zusätzlich kann ein ESB zentrale Dienste anbieten wie eine Registry, Single-Sign-On, Verschlüsselungsdienste und Datenkonvertierung.
Der andere Teil der Experten interpretiert den ESB als logische Weiterentwicklung von SOA. Der Hintergrund ist, dass der Datenstrom in Unternehmen immer von Ereignissen gesteuert wird – man spricht auch von „Event driven Enterprises“. Um ein ereignisgetriebenes Unternehmen in der IT umzusetzen, braucht man Eigenschaften der SOA wie lose Kopplungen. Der kritische Datenfluss wird vom ESB übernommen.
Fazit
Viele Unternehmen beginnen zurzeit damit, ihre IT auf serviceorientierte Architekturen (SOAs) umzustellen. Die Vorteile liegen eindeutig in einer deutlich höheren Flexibilität der IT. Neue Dienste und Produkte können so schneller eingeführt und existierende Dienste schneller an neue Anforderungen angepasst werden. Kosten und Entwicklungszeiten sinken.
Damit haben SOAs das Potenzial, das nächste bedeutende Paragdigma der Informatik zu werden. So wie etwa die objektorientierte Programmierung gegenüber der prozeduralen Programmierung ein höheres Abstraktionsniveau eingeführt hat, so gestatten SOAs eine weitere, abstrakte Sicht auf ansonsten sehr komplexe Phänomene. Dies ermöglicht meist, die hohe Komplexität der Unternehmens-IT besser zu bewältigen und flexible und wieder verwendbare Architekturen zu entwickeln. Der derzeit mit Abstand vielversprechendste Ansatz, das SOA-Konzept umzusetzen, sind die Web Services. (ala)