Lexikon

Serviceorientierte Architektur

Das Schlagwort der serviceorientierten Architektur (SOA) beherrscht gegenwärtig die Diskussion um die Gestaltung unternehmensweiter Anwendungslandschaften. Dabei wird SOA häufig gleichgesetzt mit der Verwendung von Web Services und deren assoziierten Technologien. SOA sollte aber als fachliches Architekturmuster interpretiert werden, das technologieunabhängig angewendet werden kann.

Das Schlagwort der serviceorientierten Architektur (SOA) beherrscht gegenwärtig die Diskussion um die Gestaltung unternehmensweiter Anwendungslandschaften. Dabei wird SOA häufig gleichgesetzt mit der Verwendung von Web Services und deren assoziierten Technologien. SOA sollte aber als fachliches Architekturmuster interpretiert werden, das technologieunabhängig angewendet werden kann.

Die IT in den Unternehmen steht heute vor der Herausforderung, in immer kürzeren Zyklen neue Geschäftsprozesse zu unterstützen und auf Änderungen der Unternehmensstruktur flexibel zu reagieren. Der Ansatz der serviceorientierten Architektur (SOA) verspricht, diese Aufgabe zu bewältigen und dabei gleichzeitig die IT-Kosten zu senken.

Hinter dem Begriff serviceorientierte Architektur stehen dabei aktuell sehr unterschiedliche Interpretationen. SOA definiert zum heutigen Zeitpunkt noch keine normierte Architektur oder ein klar umrissenes Begriffsgebäude. Je nach Quelle werden die verschiedenen Aspekte einer SOA unterschiedlich stark gewichtet (z. B. [2, 4, 9]). Als charakteristische Merkmale einer SOA können folgende Punkte identifiziert werden:

  • SOA ist ein Architekturmuster, das den Aufbau einer Anwendungslandschaft aus einzelnen fachlichen Anwendungsbausteinen beschreibt, die jeweils eine klar umrissene fachliche Aufgabe wahrnehmen.
  • Die Anwendungsbausteine sind lose miteinander gekoppelt, indem sie einander ihre Funktionalitäten in Form von Services anbieten.
  • Ein Service ist eine feste, definierte Leistung, die als Element eines oder mehrerer größerer Verarbeitungsabläufe verwendet werden kann. Als solcher stellt der Service eine abstrakte fachliche Sicht auf den anbietenden Anwendungsbaustein dar und verbirgt alle Implementationsdetails. Die Definition eines Services hat den Charakter einer vertraglichen Übereinkunft zwischen Serviceanbieter und Servicenutzer. Services sind tendenziell grobgranular.
  • Services werden über einen einheitlichen Mechanismus aufgerufen, der die Anwendungsbausteine plattformunabhängig miteinander verbindet und alle technischen Details der Kommunikation verbirgt. Der Servicenutzer adressiert eine anonyme Schnittstelle. Der Aufrufmechanismus enthält das Auffinden eines geeigneten, konkreten Serviceanbieters, der diese Schnittstelle implementiert.

Die elementaren Grundgedanken der SOA sind die Trennung der Zuständigkeiten nach fachlichen Gesichtspunkten sowie die Kapselung technischer Details. Damit überträgt die SOA altbewährte Prinzipien der Softwarearchitektur auf die Domäne der Anwendungslandschaft.

Nutzen und Herausforderungen

SOA verspricht ein hohes Nutzenpotential. Die wichtigsten Nutzeneffekte sind die folgenden:

• Neue oder geänderte Geschäftsprozesse können schnell und ohne großen technischen Aufwand durch Neukombination bereits bestehender Services realisiert werden. Das Unternehmen kann dadurch flexibler auf neue Marktanforderungen reagieren.

  • Das Entwurfsprinzip der Kapselung von Implementationsdetails hinter definierten Schnittstellen ist ein bewährtes Mittel zur Reduktion der Komplexität. Die Einführung einer SOA trägt daher dazu bei, die Beherrschbarkeit der unternehmensweiten IT-Struktur zu verbessern.
  • Bei Entwicklung und Wartung der IT-Systeme können mittelfristig Kosten eingespart werden. Dies geschieht durch Wiederverwendung bestehender fachlicher Komponenten sowie durch die Integration über die einheitliche SOA Infrastruktur. Diese ist bereits vorhanden und wird auf immer wieder gleiche Art und Weise verwendet.
  • Bewährte Legacy-Systeme können weiter betrieben werden, ohne dass die moderneren Systeme von technologischen Altlasten abhängig gemacht werden müssen. Die SOA bietet daher einen hohen Investitionsschutz. Aus dem gleichen Grund begünstigt die SOA eine evolutionäre Entwicklung der Anwendungslandschaft, da einzelne Komponenten durch die lose Kopplung leichter abgelöst werden können.
  • Eine bestehende, gewachsene Anwendungslandschaft kann fachlich so partitioniert und in erneuerbare Bestandteile zerlegt werden, dass eine gestufte Ablösung auch von monolithischer und gewachsener Software möglich wird.
  • Die Standardisierung von Services erleichtert das Outsourcing einzelner Geschäftsprozesse oder sogar einzelner Teile von Geschäftsprozessen.

Dem Nutzenpotential steht bei jedem SOA-Vorhaben eine Reihe von Herausforderungen gegenüber:

  • Es gibt derzeit noch keine etablierte Methodik, wie Anwendungslandschaften fachlich modelliert werden können, um zu sinnvoll definierten Services zu gelangen. Neue Ansätze einer serviceorientierten Modellierung, wie sie beispielsweise in [1] vorgeschlagen werden, sind viel versprechend aber noch nicht ausreichend detailliert, um ein konkretes Vorgehen zu bestimmen. Verfahren des Domain Engineering [3] zur systematischen Entwicklung wiederverwendbarer Komponenten für Softwareproduktfamilien sind in ihrer etablierten Form zu schwergewichtig. Die Umsetzung einer SOA verlangt daher viel Erfahrung bei der Gestaltung großer IT-Systeme sowie methodische Kreativität.
  • SOA erfordert eine stark vorausschauende Vorgehensweise sowohl bei der IT-Organisation als auch bei den Fachbereichen. Individuelle, abgegrenzte Softwareprojekte müssen neben ihren eigenen Anforderungen auch mögliche zukünftige Anforderungen sowie Anforderungen anderer, unbeteiligter Fachabteilungen bei Planung und Design berücksichtigen.
  • Lose Kopplung, Auslegung von Services auf Wiederverwendbarkeit und die Verwendung standardisierter Protokolle konkurrieren aus technischen Gründen häufig mit Performanceanforderungen. Individuelle Punkt-zu-Punkt-Systemkopplungen können wesentlich stärker auf höhere Durchsätze optimiert werden als Kommunikationsmechanismen in einer SOA-Infrastruktur.
  • Abgrenzung und Begriffswelt der serviceorientierten Architektur sind noch nicht gefestigt. Selbst der Begriff „Service“ ist nicht einheitlich definiert. Dies führt zu Reibungsverlusten bei der Kommunikation im Zuge der Vorbereitung und Durchführung von SOA-Programmen.

Technologie

Als tragende Technologie für den Aufbau einer SOA werden bereits seit mehreren Jahren Web Services und die damit verbundenen Standards diskutiert [8]. Der große Vorteil einer standardisierten Infrastruktur auf Basis von Web Services liegt in der Interoperabilität von Softwareprodukten. So statten die großen Softwareproduzenten ihre Produkte zunehmend mit Web Service-basierten Schnittstellen aus, um den Vorteil einer einfachen Integration bieten zu können. Im Bereich der Infrastrukturkomponenten stehen inzwischen Produkte von allen namhaften Herstellern bereit. Nicht alle stellen Web Services in das Zentrum, aber alle bieten zumindest die Möglichkeit Web Service-basierter Kommunikation. Beispielhaft seien hier drei Produktsuiten dargestellt.

  • SAP bietet mit der Produktsuite NetWeaver eine Integrationsplattform, die nicht nur die gängigen Web Service Standards realisiert. Herzstück ist der Web Application Server, der als Ablaufumgebung für alle weiteren NetWeaver Komponenten sowie für die modernen ERP-Produkte von SAP dient. Daneben enthält das Portfolio eine Reihe von Plattform-Komponentensystemen, die Funktionalitäten z. B. aus den Bereichen Portal, Data Warehouse, Knowledge Management und Collaboration realisieren. SAP bietet dazu mit der Enterprise Services Architecture (ESA) [9] einen architektonischen und methodischen Überbau, der die Grundprinzipien der SOA weiter detailliert.
  • IBM vereinigt unter der Bezeichnung WebSphere sein Portfolio für eine Technologie-Infrastruktur. SOA wird als Weiterentwicklung einer EAI-Infrastruktur verstanden. Zentrales Konzept ist hierbei der so genannte Enterprise Service Bus (ESB), welcher notwendige Aufgaben wie Kommunikation, Choreographie, Sicherheit und weitere Querschnittsdienste übernimmt [7]. Technologisch basiert der ESB auf Message Oriented Middleware (WebSphereMQ), ergänzt durch zusätzliche Produkte für die oben genannten Aufgaben. Neben der serviceorientierten Integration werden auch die ,,klassischen“ EAI-Paradigmen (Event-Driven und Message-Driven) durch eine zusätzliche Integrations- Layer unterstützt. IBM ermöglicht damit eine Evolution bestehender IT-Landschaften in Richtung SOA.
  • Microsoft bietet mit .NET eine ausgereifte Entwicklungs- und Integrationsplattform, die den Aufbau einer SOA durch Web Services und SOAP unterstützt. Der in der Entwicklungsumgebung Visual Studio .NET enthaltene service-oriented application designer unterstützt das Design sowie das Deployment der zugehörigen Services. Mit BizTalk wird zusätzlich ein EAI-Produkt für die Integration und Orchestrierung der Services bereitgestellt. Microsoft hat angekündigt, mit der Plattform Indigo SOA in Zukunft bereits auf Betriebssystemebene zu unterstützen.

Da ausgereifte Infrastrukturprodukte für Web Services erst seit kurzem auf dem Markt angeboten werden, verwenden gegenwärtige produktive Realisierungen in der Regel andere, etablierte Technologien. So wurden serviceorientierte Architekturen auch mit konventioneller Middleware wie z. B. CORBA oder mit Werkzeugen für Enterprise Application Integration (EAI) erfolgreich verwirklicht. Solche frühen Umsetzungen verlangten den individuellen Aufbau einer SOA-Infrastruktur sowie in vielen Fällen die Anpassung der Anwendungsbausteine an die Integrationsplattform. Mit zunehmender Standardisierung und Verbreitung von Web Services werden diese Aufwände in Zukunft entfallen.

Umsetzung

Die Einführung einer einheitlichen technischen Basis für die Interaktion der Anwendungsbausteine ist eine Voraussetzung für eine serviceorientierte Architektur. Sie ist jedoch bei weitem nicht hinreichend, um Anwendungslandschaften erfolgreich zu gestalten. Die wesentliche Aufgabe liegt vielmehr in der Entwicklung einer Anwendungsarchitektur für die IT-Landschaft, die den Rahmen für die Gestaltung und Verwendung der Services darstellt. Umfang und Komplexität dieser Aufgabe machen den Aufbau einer SOA zu einer fachlichen und organisatorischen Herausforderung.

Eine solche Anwendungsarchitektur kann zunächst in Form einer hierarchisch gestaffelten Gliederung der Systemlandschaft in abgeschlossene Komponenten mit jeweils fachlich definierten Zuständigkeiten entwickelt werden. Die Aufteilung orientiert sich an den Geschäftsprozessen des Unternehmens, wobei in der Regel auch fachlich querschnittliche Komponenten für die Verwaltung geschäftsprozessübergreifender Informationsobjekte wie z. B. das Kundenmanagement gebildet werden. Zur Verfeinerung der Architektur können zusätzliche Architektursichten betrachtet werden, die z. B. die Aufteilung in dispositive vs. operative Systeme und weiter in Frontendsysteme, Prozessintegrationssysteme, Anwendungsdienstsysteme und Systeme zur Informationsverwaltung erlauben.

Da eine unternehmensweite Anwendungsarchitektur sich nicht in einem Schritt entwickeln lässt, muss die Einführung der serviceorientierten Architektur im Rahmen eines Programms geplant und sorgfältig gesteuert werden. So können zunächst einzelne Bereiche der Anwendungslandschaft im Detail untersucht und in eine SOA transformiert werden, während andere Bereiche nur grob betrachtet werden. Die Transformation erfolgt, indem die bestehenden Anwendungen logisch in Anwendungsbausteine aufgeteilt und hinter einer Fassade von Services gekapselt werden. Neu hinzukommende Anwendungen unterstützen die technische SOA-Infrastruktur wenn möglich direkt. Mit Fortschreiten des Umsetzungsprogramms werden später auch die zunächst nicht näher betrachteten Bereiche erfasst. Das Einführungsprogrammrealisiert somit ein evolutionäres Vorgehen bei der Fortentwicklung der Unternehmens-IT.

Neben dem sicheren Verwenden von Methoden und Verfahren beim fachlichen Design erfordert die Aufgabe zwingend eine angemessene organisatorische Struktur, z. B. durch die Schaffung eines Enterprise Architect Boards. Diese Gruppe von Architekten ist unter anderem dafür verantwortlich, dass Services so definiert werden, dass sie unternehmensweiten Designrichtlinien entsprechen und fachlich korrekt im Unternehmenszusammenhang eingebettet sind. Nur so kann die angestrebte Wiederverwendbarkeit auch tatsächlich erreicht werden.

SOA in der Praxis

Dass die Nutzenpotenziale sich tatsächlich realisieren lassen, zeigen konkrete Erfahrungen aus den Projekten. In einem hier beispielhaft betrachteten Vorhaben wurde ein Ausschnitt der Anwendungslandschaft, der die operativen Kern- Anwendungen eines Unternehmens umfasst, in eine SOA transformiert. Fehlendes Management bei der Fortentwicklung und eine technisch sehr enge Kopplung der Komponenten hatten zu einer nahezu unwartbaren Anwendungslandschaft geführt. Schon während der Etablierungsphase konnte erreicht werden, dass neue Funktionalitäten durch kürzere Releasezyklen schneller produktiv gesetzt werden konnten. Wesentlich dazu beigetragen hat auch, dass die Releasezyklen der einzelnen Komponenten durch die lose Kopplung nun voneinander unabhängig geplant werden konnten. Sowohl der Aufwand für Wartung als auch für Neuentwicklung konnte signifikant reduziert werden. Darüber hinaus konnte ein Rückgang der Fehler im Produktivsystem festgestellt werden.

Die Möglichkeiten zur Wiederverwertung fachlicher Funktionalitäten in einer SOA werden z. B. in [5] belegt. So konnten hier durch Kapselung einer Mainfraim-basierten Zentralanwendung hinter serviceorientierten Fassaden in vier Jahren mehr als 9 000 Personentage eingespart werden. Dies gelang durch die sukzessive Einführung von ca. 725 Services, von denen 50% von wenigstens zwei Nutzern nachgefragt werden. Neu entwickelte Anwendungen verwenden durchweg wenigstens einen bereits bestehenden Service.

Die Möglichkeit, Prozesse oder Prozessteile durch Outsourcing kosteneffizienter abzuwickeln, ist dagegen in der Praxis noch ohne Bedeutung, da für diese Aufgabe die fachlichen Service-Standards noch fehlen.

Für die Erstellung einer Wirtschaftlichkeitsberechnung für SOA-Vorhaben ist die Anwendung klassischer Verfahren der Investitionsrechnung notwendig [6]. Dabei ist der gesamte Lebenszyklus der SOA, insbesondere die Betriebsphase, zu betrachten. Durch eine Cost Benefit-Analyse, die im Vorfeld einer SOA-Einführung für einen großen Energieversorger durchgeführt wurde, konnte nachgewiesen werden, dass der Return on Invest (ROI) nach 1,5 Jahren zu erwarten ist. Selbst bei einer pessimistischen Einschätzung ergab sich ein ROI von 3 Jahren.

Fazit

Die wachsende Verfügbarkeit von Web Servicebasierten Infrastrukturkomponenten sowie die Öffnung von fachlichen Softwareprodukten durch Web Service-basierte Schnittstellen rückt die einfache technische Umsetzung einer serviceorientierten Architektur in greifbare Nähe. Die Methodik, nach der eine unternehmensweite Anwendungsarchitektur der IT-Landschaft entwickelt werden kann, ist aber noch nicht etabliert. Die Tragfähigkeit dieser Architektur beeinflusst aber entscheidend die Wiederverwendbarkeit der Services und damit den Nutzen, den eine SOA erbringen kann.

Literatur

1. Arsanjani, A.: Service-oriented modeling and architecture, IBM DeveloperWorks, SOA and Web Services, http://www.ibm.com/developerworks/webservices/library/wssoa- design1/

2. Booth, D. et al. (Hrsg.): Web Services Architecture, W3C Working Group Note, S. 61, http://www.w3.org/TR/ws-arch

3. Czarnecki, K., Eisenecker, U.: Generative Programming, Methods, Tools, and Applications, Addison Wesley, 2000

4. Datz, T.: What You Need to Know About Service-Oriented Architecture, CIO Magazine, Jan. 2004 http://www.cio.com/archive/011504/soa.html

5. Hagen, C.: Services, Events and Contracts – SOA at Credit Suisse, SOA Days Business Conference, Bonn, 16. + 17. 2. 2005

6. Heimann, Th. und Kappes, R.: Mit SOA aus der Kostenfalle, IT Management, November 2004

7. Keen, M. et al.: Patterns: Implementing an SOA Using an Enterprise Service Bus, IBM Redbooks, [http://www.redbooks.ibm.com/redbooks/pdfs/sg246346.pdf]

8. Kossmann, D., Leymann, F.: Web Services, Informatik-Spektrum 27(2), 168–171 (2004)

9. Woods, D.: Enterprise Services Architecture, SAP Press, 2004

Autoren und Copyright

Dr. Jan-Peter Richter

E-Mail: jan-peter.richter@sdm.de

sd&m AG, software design & management

Lübecker Straße 1

22087 Hamburg

Dr. Harald Haller

E-Mail: harald.haller@sdm.de

Peter Schrey

E-Mail: peter.schrey@sdm.de

sd&m AG, software design & management

Carl-Wery-Straße 42 81739 München

© Springer-Verlag 2005