Serviceorientierte Architektur (SOA). Modewort von Softwareanbietern oder ernstzunehmendes Konzept?

Inhaltsverzeichnis

Abbildungsverzeichnis

1 Einführung

2 Herleitung des Begriffs „Serviceorientierte Architektur“
2.1 Softwarearchitektur
2.2 Serviceorientierung
2.3 Definition

3 Das Konzept hinter SOA
3.1 Hauptmerkmale einer SOA
3.2 Das Herz von SOA: Dienste
3.3 Rollen und Aktionen in einer SOA
3.3.1 Dienstanbieter
3.3.2 Dienstverzeichnis
3.3.3 Dienstnutzer
3.3.4 Die Aktionen
3.4 Der Enterprise Service Bus als Infrastruktur

4 SOA in der Praxis
4.1 Infrastruktur zur standardisierten Integration
4.2 Simplifizierung der bestehenden Applikationsarchitektur
4.3 Vermarktung der Dienste als IT-Produkte
4.4 Beispiel: Swiss Banking Platform der Zuger Kantonalbank

5 Die Entwicklung von SOA
5.1 Historie
5.1.1 Generation 1: Point-to-Point Integration
5.1.2 Generation 2: Message Based Integration
5.1.3 Generation 3: Service-oriented Integration (SOA)
5.2 Der Hype um SOA
5.2.1 Die Realisierung des Echtzeitunternehmens
5.2.2 Die Versprechungen der Software-Anbieter
5.2.3 Der Ansturm auf Web Services (und Abgrenzung zu diesen)
5.3 Prognose für die Zukunft

6 Zusammenfassung

Literaturverzeichnis

Abbildungsverzeichnis

Abbildung 1: Der „SOA-Tempel“¹⁰

Abbildung 2: Rollen und Aktionen¹⁰

Abbildung 3: Architektur des ESB¹⁸

Abbildung 4: Domänenarchitektur der Swiss Banking Platform²²

Abbildung 5: Generation 1: Point-to-Point Integration²⁴(Abb. leicht verändert)

Abbildung 6: Generation 2: Message Based Integration²⁴

Abbildung 7: Generation 3: Service-oriented Integration²⁴

Abbildung 8: Einsparpotenzial durch SOA¹⁴

Abbildung 9: Entwicklung von Web Services in Deutschland (2002-2005)²⁸

Abbildung 10: Web Services²⁴

Abbildung 11: SOA-basierte Web Services ²⁴

Ariane Gramm 4 Serviceorientierte Architektur

Abstract

Serviceorientierte Architektur - Mythos, Modewort und ernstzunehmendes Konzept.

Serviceorientierte Architektur ist das Schlagwort, das so viele kennen aber nur so wenige verstehen. Es ist ein oft benutztes Modewort, welches die unterschiedlichsten Softwareanbie- ter missbrauchen, um ihre Produkte zu verkaufen. Und serviceorientierte Architektur ist das zukunftsweisende Konzept zur standardisierten Applikationsintegration, welches zu Recht immer häufiger eingesetzt wird, um Geschäftsprozesse flexibel erstellen, anpassen und effek- tiv einsetzen zu können. Die vorliegende Arbeit geht den Irrtümern der serviceorientierten Architektur auf den Grund und erforscht die Historie, das Konzept und die Anwendungsgebie- te derselben, um eine Prognose über die Zukunft dieser trendigen Architektur geben zu kön- nen.

1 Einführung

Wir befinden uns in einer sich durch Globalisierung und technologischen Fortschritt immer schneller entwickelnden Welt. Die bestehenden Applikationslandschaften vieler Unternehmen kennzeichnen sich dessen ungeachtet durch Inflexibilität und eine starke Heterogenität, ent- standen aus einer Vielzahl unterschiedlicher Informationssysteme, die über die Jahre hinweg zusammen gekommen sind. Änderungen können nur schwer vorgenommen werden. Die War- tung ist äußerst kostspielig. Zugleich steht seitens der Unternehmen der Wunsch im Raum, auf die sich stetig verändernden Markt-/Umweltbedingungen zeitgleich (quasi in Echtzeit) reagieren zu können, um so wettbewerbsfähig zu sein und das optimale Geschäftsergebnis zu erzielen. Die Realisierung des so genannten „Echtzeitunternehmens“ ist schon seit langem ein Traum, dem die vorhandenen Applikationen nicht gerecht werden können.

Serviceorientierte Architekturen (kurz: „SOA“) sollen diesen Traum nun endlich verwirkli- chen. Sie sind die trendweisende Lösung, um Geschäftsprozesse effizient und effektiv abbil- den, anpassen und einsetzen zu können. Aufgrund der großen Hoffnungen, die dadurch in SOA gesteckt werden, kommt es jedoch auch zu zahlreichen Überinterpretationen und Miss- verständnissen, die hauptsächlich den Marketingstrategen der Softwareanbieter zuzuschreiben sind. Die vorliegende Arbeit verfolgt daher das Ziel, zu klären, worum es sich bei dem My- thos der serviceorientierten Architektur handelt und in der Folge, die gegenwärtigen Missver- ständnisse zu benennen und aufzuklären.

Dabei wird zunächst der Begriff der serviceorientierten Architektur hergeleitet, was aufgrund der Vielzahl an uneinheitlichen Definitionen über die Begriffsbestandteile Softwarearchitek- tur und Serviceorientierung erfolgen muss. Daraufhin kann auf die Details von SOA einge- gangen werden. Merkmale, Services, Rollen, Rollenaktionen und Enterprise Service Bus wer- den erläutert. Im dritten Kapitel werden konkrete Anwendungsgebiete vorgestellt, die auch anhand eines Beispiels aus dem Finanzsektor untermalt werden. Abschließend werden dann die Vergangenheit, Gegenwart und Zukunft von SOA beleuchtet, um eine Prognose über des- sen Entwicklung zu wagen.

2 Herleitung des Begriffs „Serviceorientierte Architektur“

Zunächst erfolgt eine Herleitung der Begriffe „Architektur“ oder genauer „Softwarearchitektur“ und „Serviceorientierung“, die schließlich in eine Definition von „Serviceorientierter Architektur“ mündet. Letzteres stellt ein schwieriges Unterfangen dar, weil sich die Literatur nicht über eine einheitliche Begriffsdefinition einig ist. Dennoch soll hier der Versuch unternommen werden, einen allgemeingültigen Konsens zu finden, der sich aus der Begriffsherleitung und beispielhaften Definitionen ergeben wird.

2.1 Softwarearchitektur

Eine „Softwarearchitektur“ lässt sich laut Balzert definieren als „strukturierte oder hierarchi- sche Anordnung der Systemkomponenten sowie Beschreibung ihrer Beziehungen“¹. Es werden also sowohl statische (Komponenten) als auch dynamische (Zusammenwirken der Komponenten über Schnittstellen) Aspekte betrachtet.²Was eine Komponente im Detail darstellen soll, ist abhängig von der jeweiligen Art der verwendeten Architektur. Die wohl bekanntesten Architekturmuster (Arten von Softwarearchitekturen) werden hier beleuchtet:

- Das bewährteste Architekturmuster ist die hierarchische Schichtenarchitektur, bei der Komponenten, die sich auf einer bestimmten Schicht befinden, immer nur auf solche Komponenten zugreifen können, die sich auf einer darunter liegenden Schicht (auch über mehrere Schichten hinweg) befinden.
- Bei der Client/Server-Architektur greifen meist viele Clients auf wenige Server zu.
- In Peer-to-Peer-Architekturen können Komponenten je nach Bedarf sowohl die Client- als auch die Server-Rolle einnehmen.
- Auch serviceorientierte Architekturen erfreuen sich einer steigenden Popularität.

Die Qualität der jeweiligen Softwarearchitektur ist schwer zu quantifizieren und meist nur subjektiv über die beiden Kriterien „Verständlichkeit“ und „Ästhetik“ zu bewerten. Eine Möglichkeit festzustellen, wie gut oder wie schlecht sie ist, besteht aber in der Bestimmung der Güte des Softwaresystems, welches basierend auf der Architektur erstellt wird. Zeichnet sich ein System unter anderem insbesondere durch Sicherheit, Verlässlichkeit, Performanz, Wiederverwendbarkeit der Komponenten und Änderbarkeit aus, so können ihm und damit der architektonischen Grundlage Vertrauen geschenkt werden.³

2.2 Serviceorientierung

Laut Gartner Research wird bei der Serviceorientierung die Technik in den Hintergrund ge- stellt, während den Geschäftsprozessen eines Unternehmens alle Beachtung zukommt.⁴

„Geschäftsprozesse sind funktionsübergreifende Verkettungen wertschöpfender Aktivitäten, die von Kunden erwartete Leistungen erzeugen und deren Ergebnisse strategische Bedeutung für das Unternehmen haben.“ ⁵

Diese Prozesse liegen zumeist in einer technischen Form vor, in der die Fachabteilung sie nur schwerfällig und nicht ohne die Hilfe der IT-Abteilung anpassen kann. Im Gegenzug hat die IT wenig Wissen über die Zusammenhänge und Ziele der Prozesse, welche durch die Fachabteilung formuliert werden.

Der Servicegedanke soll hier Abhilfe verschaffen, indem die Geschäftsprozesse zunächst in Bausteine aufgebrochen, analysiert, dokumentiert und schließlich entsprechend ihrer jeweili- gen fachlichen Aufgabe gegliedert werden (sog. „Orchestrierung“). Die Orchestrierung er- möglicht es, die Bausteine (sog. „Services“) immer wieder neu zusammenzusetzen, auszu- bauen und zu ändern.⁶Ein Service ist demnach „eine feste, definierte Leistung, die als E- lement eines oder mehrerer größerer Verarbeitungsabläufe verwendet werden kann“⁷.

Ziel der Serviceorientierung ist also, Prozesse und Teilprozesse möglichst umfassend aus ser- viceorientiert strukturierten Fachkomponenten zu orchestrieren.⁸Dadurch wird die IT au- tomatisch näher am Geschäft positioniert, wodurch sie sinnvoller eingesetzt und klarer ver- standen werden kann.⁶Die Arbeit der Fachabteilung wird erleichtert, da die Prozesse und deren Anpassbarkeit an sich ständig wandelnde Umweltbedingungen beschleunigt und flexi- bilisiert werden. Die Serviceorientierung soll somit das so genannte „Echtzeitunternehmen“ realisieren (Vgl. Kap. 5.2.1).

2.3 Definition

Nun wird der Versuch unternommen, eine Definition für eine serviceorientierte Architektur aufzuzeigen.

Der Begriff „Serviceorientierte Architektur“ wurde im Jahre 1999 von Gartner Research geprägt. Sie definierten SOA damals so: “Service-oriented architecture is a best-practice architecture pattern for the systematic design of request/reply applications. Its primary intentions are business-level software modularity and rapid, nonintrusive reuse of business software in new runtime contexts.”⁹

Diese Definition ist jedoch in der Literatur nicht allgemein anerkannt. Zahlreiche weitere Ansätze existieren, die in ihrer Aussage teilweise stark voneinander abweichen. Im Folgenden einige Beispiele:

- „Unter einer SOA versteht man eine Systemarchitektur, die vielfältige, verschiedene
und eventuell inkompatible Methoden oder Applikationen als wieder verwendbare und offen zugreifbare Dienste repräsentiert und dadurch eine plattform- und sprachenunabhängige Nutzung und Wiederverwendung ermöglicht.“¹⁰
- „SOA ist ein Architekturmuster, das den Aufbau einer Anwendungslandschaft aus
einzelnen fachlichen Anwendungsbausteinen beschreibt, die jeweils eine klar umrisse- ne fachliche Aufgabe wahrnehmen. Die Anwendungsbausteine sind lose miteinander gekoppelt, indem sie einander ihre Funktionalitäten in Form von Services anbieten.“ ⁷
- “[…] a software architecture that is based on the key concepts of an application front
end, service, service repository, and service bus.” ¹¹
Ariane Gramm 7 Serviceorientierte Architektur
- “A design model based on the concept of encapsulating application functionality
within services that interact via a common communications protocol.”¹²
- “[…] an approach to the development of loosely coupled, protocol-independent

distributed applications […].”¹³

Wie man sieht, bestehen zwar immer wieder Überlappungen in den Definitionen, jedoch feh- len meistens Aspekte in der einen, die von einer anderen als entscheidend angesehen werden. Bei sämtlichen Definitionen gibt es eine Gratwanderung „zwischen einer zu allgemeinen, alles erschlagenden Formulierung und einer sehr speziellen, die auf viele Fälle nicht anwend- bar ist“.¹⁰

Ausgehend von den in den beiden obigen Abschnitten getroffenen Aussagen über Softwarear- chitektur und Serviceorientierung und dem Versuch, einen Konsens in den genannten Defini- tionen zu finden, ergibt sich folgende Definition für eine serviceorientierte Architektur:

„SOA stellt die fachlichen Dienste (Services) eines Unternehmens - als Basis einer Integrati- on von Anwendungen - in den Mittelpunkt der Betrachtungen. Wesentliche Ziele von SOA sind:

- lose Kopplung von Softwaresystemen, x höhere Agilität von Geschäftsprozessen,
- verbesserte Wiederverwendung sowohl von Softwaresystemen als auch von Ge- schäftsprozessen.“ ¹⁴

3 Das Konzept hinter SOA

Nachdem im vorangegangenen Kapitel die Begriffsbestimmung der serviceorientierten Architektur erfolgt ist, wird nun zunächst näher auf die in der Definition erwähnten Eigenschaften eingegangen. „Lose Kopplung“ ist dabei nur ein wesentliches Merkmal einer SOA, welches im folgenden Abschnitt unter anderem behandelt wird.

3.1 Hauptmerkmale einer SOA

Die Eigenschaften einer SOA können durch einen so genannten „SOA-Tempel“ dargestellt werden, der sich durch ein dreigeteiltes Fundament und vier Säulen auszeichnet (siehe Abbildung 1).¹⁰Hierbei muss jedoch bedacht werden, dass lediglich die wichtigsten Merkmale einer SOA abgebildet werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Der „SOA-Tempel“¹⁰

Das Fundament einer serviceorientierten Architektur beinhaltet die Verwendung von offenen Standards, um die Kommunikation mit allen potenziellen Teilnehmern zu ermöglichen. Dies befähigt SOA dazu, von einer breiten Masse an Anwendern akzeptiert zu werden. SOA stei- gert somit gleichzeitig die Verbreitung von Standards. Die Verwendung dieser ist nämlich eine unabdingbare Grundvoraussetzung für den Gebrauch einer serviceorientierten Architek- tur.

Die Sicherheit wird als weiterer Fundamentbaustein genannt, bezieht sich aber vielmehr auf die technologische Umsetzung einer SOA beispielsweise mittels Web Services, da Merkmale wie Vertraulichkeit, Authentifizierung, Autorisation und Konsistenz nur durch die jeweilige Technologie erfüllt werden können.

Unter Einfachheit wird die Beachtung des Softwareentwicklungsparadigmas „Trennung von Schnittstelle und Implementierung“ verstanden, welche die aufwandslose Wiederverwendung von Diensten in anderem Zusammenhang oder verschiedenen Umgebungen ermöglicht. Auch dieses Merkmal sorgt für eine breite Akzeptanz, da es die Umsetzung von SOA erleichtert.

Diese drei Bestandteile des Fundaments werden als Voraussetzungen für eine serviceorientierte Architektur angesehen, wobei sich der Aspekt der Sicherheit teilweise aus der Einfachheit (erst durch die Trennung von Schnittstelle und Implementierung kann die Architektur effizient geschützt werden) und der Verwendung von Standards (Standards sind erprobt und daher von Grund auf sicher) zusammensetzt und damit im Tempel nicht korrekt abgebildet ist. Der Erfolg einer SOA wäre ohne dieses Fundament nicht gewährleistet.

Die vier Säulen des Tempels beschreiben die Merkmale, welche eine serviceorientierte Archi- tektur ausmachen und einzigartig erscheinen lassen. Dazu gehört insbesondere die lose Kopp- lung von Diensten. Dies bedeutet, dass Dienste möglichst unabhängig von den Applikationen oder anderen Diensten, die sie aufrufen, erstellt werden. Hierdurch wird die independente Weiterentwicklung von Diensten oder Servicenutzern (Austausch oder Adaption von Servi- ces) ermöglicht. Ein weiteres Merkmal, welches den Gedanken der losen Kopplung noch er- weitert, ist die Verteiltheit. Die einzelnen Dienste, die in sich geschlossen und damit von mo- dularer Struktur sind, können sich an beliebigen Orten unabhängig vom Einsatzzweck oder den potenziellen Nutzern befinden. Dies ermöglicht ein Verzeichnisdienst, welcher zur Verfü- gung stehende Dienste registriert und dem potenziellen Nutzer bei Bedarf die Suche nach spezifischen Diensten in diesen Registrierungen gestattet. Diese Funktion ist daher vergleich- bar mit den Gelben Seiten.

Die vierte Säule beschäftigt sich mit der Prozessorientierung. Dienste stellen (Teil-)Prozesse eines Unternehmens dar, die jeweils für sich eine spezifische Funktionalität/Aufgabe erfüllen. Durch Orchestrierung können Dienste in ständig wechselndem Kontext zu einem so genann- ten „Workflow“ zusammengesetzt werden, wodurch ein Arbeitsablauf abgebildet und schnell angepasst werden kann. Eine flexible Wiederverwendung von Diensten ist dadurch gewährleistet.

Was erneut nicht aus der Säulenmetapher des SOA-Tempels hervorgeht, ist, dass die Modularität und lose Kopplung von Diensten die Voraussetzung für eine Prozessorientierung bilden. Um diesen Zusammenhang zu verdeutlichen, wird im folgenden Abschnitt detailliert auf Dienste eingegangen.

3.2 Das Herz von SOA: Dienste

Serviceorientierte Architekturen beschäftigen sich unter anderem mit „Entwurf, Implementierung, Deployment, Wiederverwendung, vereinfachter Verwendung und Suche nach Services“. ¹⁵ In einer solchen Architektur dienen Dienste zur Vereinfachung des Zugriffs auf die Logik einer Komponente. Während eine Komponente die technische Implementierung der Architektur in den Mittelpunkt stellt, ist ein Dienst für die fachliche Abbildung eines Geschäftsprozesses auf der Komponente zuständig.

[...]