Der Beitrag beschreibt das grundlegende Konzept einer Serviceorientierten Architektur. Dabei wird auf die Zusammenhänge zwischen den Architekturelementen und deren Beziehungen untereinander eingegangen. Neben einer Beschreibung implizierter Prinzipien werden auch kritische Aspekte aufgezeigt, die zur Nutzung der Vorteile einer Serviceorientierten Architektur zu berücksichtigen sind.
Architekturelemente und Beziehungen in einer SOA
Eine Serviceorientierte Architektur (SOA) ist ein Strukturmuster, das auf die Minimierung direkter und fester Abhängigkeitsbeziehungen zwischen den Elementen eines verteilten Softwaresystems abzielt. Nach dem grundlegenden Konzept einer SOA bestehen systeminterne Beziehungen jeweils nicht direkt zwischen zwei entfernten Softwareelementen, sondern jeweils zwischen einem Element und einer Eigenschaftsbeschreibung eines anderen Elements in Form einer Anforderungsspezifikation. Sowohl Anforderungsspezifikationen an potentiell vorhandene als auch Spezifikationen tatsächlich vorhandener Softwareelemente beziehen sich dabei auf die Beschreibung der funktionalen und nicht-funktionalen Eigenschaften dieser Elemente. Ein eigenständiges und über ein Netzwerk durch nachrichtenbasierte Kommunikation nutzbares Softwareelement, das Funktionen nach außen anbietet und dessen exportierte Schnittstelle durch eine eindeutige Spezifikation beschrieben ist, die öffentlich oder für eine definierte Zielgruppe zugänglich ist, wird als Dienst (Service) bezeichnet. Die Zuordnung von Diensten zu deren Spezifikationen wird über ein Dienstverzeichnis (Service Registry) organisiert. Die tatsächliche Bindung zwischen den Softwareelementen Dienstnutzer (Service Consumer) und Dienstanbieter (Service Provider) erfolgt zur Ausführungszeit der Programmlogik des Dienstnutzers durch die dynamische Zuordnung (on-demand) zwischen den geforderten und den offerierten Eigenschaften von Diensten, die im Dienstverzeichnis registriert sind. Diese Beziehungsstruktur wird häufig auch als Dreieckmodell (SOA-Triangle) dargestellt [vgl. Dostal, Jeckle, Melzer 2005].
Abb. 1: SOA-Dreieck
Es besteht demnach keine feste (enge) Kopplungsbeziehung zwischen Dienstnutzer und Dienstanbieter, da die Kopplung beider Elemente abhängig von einem Vergleich geforderter und angebotener funktionaler und nicht-funktionaler Eigenschaften ist. Prinzipiell kann die Durchführung eines solchen Vergleichs zu unterschiedlichen Zeitpunkten bei veränderlichem Dienstangebot zu unterschiedlichen Ergebnissen führen. Deshalb wird auch von einer losen Kopplung gesprochen [vgl. Vogel u.a. 2005, S. 114ff.]. In Abbildung 2 ist die Umsetzung des Prinzips der losen Kopplung in einer SOA modellhaft dargestellt.
Abb. 2: Feste Kopplung vs. lose Kopplung in einer SOA
Dienstnutzer sind deshalb nicht direkt sondern nur indirekt von konkreten Diensten abhängig, da Dienste prinzipiell einfach ersetzbar sind. Ein verteiltes Softwaresystem, das auf einer SOA basiert, besteht deshalb bereits in seiner Struktur aus voneinander isolierbaren Elementen, die durch andere Elemente ausgetauscht werden können. Im Zusammenhang mit der zunehmend geforderten Flexibilität von Softwaresystemen zur Reaktion auf veränderliche Softwareanforderungen bietet SOA eine Strukturierungsgrundlage, die eine Änderung von Dienstbedarfen und Dienstangeboten unabhängig voneinander erlaubt.
SOA zur Flexibilisierung von Prozessen
Eine SOA impliziert das Konstruktionsprinzip der Prozessorientierung [vgl. Papazoglou, van den Heuvel 2007, S. 389] wodurch die Festlegung der Art und Weise der Nutzung mehrerer Dienste zur Umsetzung übergeordneter Aufgaben zunächst zur Erstellung von Prozessmodellen führt. Aus Sicht eines Dienstnutzers wird der Vorgang zur Erstellung eines Prozessmodells Orchestrierung genannt. Ausführbare Prozessmodelle beinhalten Aktivitätsbeschreibungen, die jeweils die Art und Weise einer Dienstnutzung spezifizieren. Eine Softwarekomponente, die die Ausführung von Prozessmodellen ermöglicht, wird als Process Execution Engine bezeichnet. Gemäß dem Prinzip zur Vermeidung fester Beziehungen zwischen Dienstnutzer (Prozess) und Dienstanbietern können Prozessmodelle zunächst einfach erstellt und verändert werden, was i. d. R. durch eine graphische Darstellung von Prozessmodellen mit Hilfe eines Prozess-Editors erreicht wird. Werden Prozessmodelle manuell erstellt, können Spezifikationen vorhandener Dienste von der erstellenden Person aus dem Dienstverzeichnis abgerufen werden. Der Vergleich zwischen den geforderten und offerierten Eigenschaften von Diensten erfolgt dabei manuell. Dadurch wird der Grundsatz zur Vermeidung direkter Kopplungen zwischen Prozessen und Diensten nur eingeschränkt verfolgt, da ein Vergleich zwischen angebotenen und benötigten Diensteigenschaften nicht zur Ausführungszeit sondern zur Designzeit von Prozessen erfolgt. Zur Aufhebung oder zur Veränderung der Kopplung zwischen Prozessen und Diensten ist dabei ebenfalls ein manueller Engriff notwendig. Durch das Vorhandensein von veränderbaren und intuitiv verständlichen Prozessmodellen wird dieser Eingriff im Vergleich zu alternativen Modellrepräsentationen (z.B. Programmquelltexte oder Maschinencode) vereinfacht, da letztere ein höheres Grundwissen voraussetzen und deshalb einen höheren Aufwand erfordern. Die lose Kopplung ergibt sich in diesem Fall indirekt durch die vereinfachte Änderbarkeit ausführbarer Prozesse. Alternativ können Prozessmodelle auch formale Anforderungsspezifikationen enthalten, die zur Ausführungszeit des Prozesses zu einem Vergleich zwischen geforderten und offerierten Diensteigenschaften genutzt werden. Ebenfalls ist auch eine automatische Erzeugung von Prozessen auf der Grundlage einer formalen Anforderungsspezifikation einer komplexen Aufgabe möglich, wenn eine Nacheinanderausführung mehrerer bekannter Dienste diese Anforderungen erfüllen kann [vgl. Marx Gómez, Lübke 2008].
Durch das Vorhandensein von Prozessmodellen wird eine Zuordnung von fachlichen Aufgaben zu Diensten möglich, da Prozessmodelle ebenfalls als Grundlage zur Abstraktion komplexer Softwarefunktionen und somit zur Modellierung der funktionalen Ablauforganisation in Betrieben bzw. Unternehmen unter Berücksichtigung beteiligter Softwaredienste genutzt werden können. Bei der Etablierung funktionaler Organisationsstrukturen mit inhärenter Orientierung zur Forcierung von Handlungsalternativen und der Reaktionsfähigkeit auf zukünftige Umgebungsbedingungen ist bei der Planung betrieblicher Prozessstrukturen ein direkter Bezug zu softwaregestützten Prozessen möglich. Idealerweise lassen sich betrieblichen Aufgaben Softwaredienste zuordnen, die bereits vorhanden oder noch bereitzustellen sind. Ist dies der Fall, können ausführbare Prozessmodelle mit Softwaredienstbezug aus betrieblichen Prozessen abgeleitet werden, deren Aktivitäten sich auf betriebliche Aufgaben beziehen. Eine SOA bildet dabei eine Grundlage zur prozessübergreifenden Wiederverwendbarkeit von Softwarediensten, wodurch zusätzlich Kostensenkungspotentiale bei der Entwicklung, dem Betrieb und der Wartung verteilter Softwaresysteme entstehen.
Herausforderungen durch SOA
Bei der Umsetzung einer SOA ist kritisch zu berücksichtigen, dass die Etablierung von Standards zur eindeutigen Spezifikation und zur plattform- und programmiersprachen-unabhängigen Bereitstellung und Nutzung von Diensten mit einem hohen Aufwand verbunden sein kann, der im konkreten Anwendungsfall in Bezug zum potentiellen Nutzen von SOA zu setzen ist. Weiterhin ist auch die Sicherheit von SOA-basierten Softwaresystemen unter dem Aspekt veränderlicher Objekte und deren Relationen untereinander zu betrachten, so dass an Sicherheitsmechanismen im Kontext der Authentifizierung und Zugriffskontrolle sowie der Vertraulichkeits- und Integritätssicherung flexibilitätsfördernde Anforderungen zu stellen sind. Die Organisation von Rollen und Verantwortlichkeiten zur Regulierung und Kontrolle einer SOA im Sinne der anwendungsbezogenen Zielerreichung (SOA-Governance) erfordert eine Abstimmung und Verflechtung mit übergeordneten Organisationsstrukturen, die aus dem Anwendungskontext einer SOA hervorgehen. Durch die mit SOA einhergehende Selbstverantwortlichkeit (Autonomie) beteiligter Rollen bei der Nutzung und Bereitstellung von Diensten resultiert typischerweise auch in Unternehmensstrukturen ein SOA-Bezug, wodurch Verantwortungsbereiche und Entscheidungsbefugnisse von Personen oder Abteilungen zur Umsetzung und dem Betrieb einer SOA festgelegt werden.
SOA aus technischer Sicht
Aus technischer Sicht sind zur Umsetzung von Services zunächst grundlegende Technologien zur Kommunikation in verteilten Softwaresystemen, wie beispielsweise Java RMI oder .NET Remoting zu nennen, die prinzipiell zunächst einen entfernten Zugriff auf Anwendungsfunktionen im Sinne eines Remote Procedure Calls (RPC) ermöglichen und Objekte und Komponenten auf entfernten Systemen in einer lokalen Laufzeitumgebung repräsentieren können. Jedoch werden durch solche Techniken nicht alle Anforderungen an eine SOA erfüllt. Beispielsweise werden durch die Common Object Request Broker Architecture (CORBA) zusätzlich Service-Implementierungen in verschiedenen Programmiersprachen und auf verschiedenen Plattformen möglich und es werden Konzepte zur Publikation und zur Suche nach Services berücksichtigt. Deshalb wird häufig auch davon gesprochen, dass CORBA eine Möglichkeit zur Umsetzung von SOA bietet, bzw. bot, da diese Technologie aufgrund der Kompliziertheit mit zunehmender Zeit durch Web-Services abgelöst wird. Web-Service-Standards wie SOAP, die Web Services Description Language (WSDL) und der Universal Description, Discovery and Integration (UDDI)-Standard, kommen neben weiteren Standards bei der Umsetzung von Web-Services zum Einsatz. Seit der Entstehung der Open Grid Service Architecture (OGSA) ist ein verstärkter Einfluss von Web-Service-Konzepten und -technologien auf Grid-Systemarchitekturen zu erkennen.
Aus dem Kerngedanken der losen Kopplung von Services in einer SOA, d.h. der expliziten Entkopplung direkter Service-Instanzen von Softwaresystemstrukturen und einer variablen Auswahl von Service-Instanzen zur Systemlaufzeit resultieren mehrere für die Praxis relevante Teilkonzepte, die den Aufbau von SOA-Systemen aus technischer Sicht beeinflussen bzw. charakterisieren. Im Vergleich zu artverwandten jedoch vereinfachten Konzepten der Objektorientierten bzw. Komponentenorientierten Systementwicklung implizieren SOA-Systeme in der Regel folgende wichtige Zusatzeigenschaften [vgl. Mathas 2008, S. 18f.]:
-
Ausfallsicherheit durch Redundanz von Services (Mehrfachinstanziierung)
-
Deployment durch Service-Management-Tools
-
Service-Versionierung über eine SOA-Registry
-
Technologie- und Plattformunabhängigkeit
-
Load Balancing durch Mehrfachinstanzen von Services
-
Performanzverlust zugunsten einer hohen Technologievarianz
-
Monitoring (Überwachung) mit Hilfe von SOA-Management-Tools
-
Service-bezogene Zugriffskontrollfunktionen mit standardisierten Verfahren
-
Einfache Erweiterbarkeit durch die Bereitstellung neuer (unabhängiger) Services
Das SOA-Konzept führt aus technischer Sicht die Vorarbeiten aus den Bereichen der Objektorientierung und Komponentenorientierung zur einer erweiterten Integrationstechnologie für verteilte Softwaresysteme zusammen, bei der die Prinzipen der losen Kopplung und der Schnittstellenorientierung essentielle Bestandteile sind und durch technische Zusätze und Standards unterstützt werden. Die aufgeführten technischen Erweiterungen erfordern weitere konkrete Teilfunktionen einer SOA-Integrationsplattform, wie beispielsweise zur Nachrichtenvermittlung (Message-Mediation), z.B. mittels XSLT, oder zur Service-Adressierung und Auflösung von Zielservices zum Zeitpunkt des Aufrufs bzw. implizites Nachrichten-Routing [vgl. Mathes 2008, S. 22].
Literatur
Dostal, W. ; Jeckle, M. ; Melzer; I.: Serviceorientierte Architekturen mit Web Services: Konzepte – Standards – Praxis. München : Spektrum Akademischer Verlag, 2005.
Marx Gómez, J. ; Lübke, D.: Konzept und Support für das Testen von Services und Service-Kompositionen. ERP-Management. In: Zeitschrift für unternehmensweite Anwendungssysteme: Sonderheft Schwerpunktthema Serviceorientierte Architekturen. Berlin : GITO Verlag, 2008, S. 29-31.
Mathas, C.: SOA Intern. Praxiswissen zu Service-orientierten IT-Systemen. München, Wien : Carl Hanser Verlag, 2008.
Papazoglou, M. P. ; van den Heuvel, W.-J.: Service oriented architectures: approaches, technologies and research issues. In: International Journal on Very Large Data Bases (VLDB), 16 (2007), Nr. 3,S. 389-415.
Vogel, O. ; Arnold, I. ; Chughtai, A. ; Ihler, E. ; Mehlig, U. ; Neumann, T.: Software-Architektur. Grundlagen-Konzepte-Praxis. München : Spektrum Akademischer Verlag, 2005.
