SOA im Winter – Teil 1 von 2

Nachdem der SOA-Begriff von den einschlägigen Anbietern in den letzten Jahren dermaßen überreizt wurde, dass man inzwischen schon fast von einem Brechreiz sprechen muss, haben wir wieder einmal ein Problem: SOA ist prinzipiell hilfreich, aber keiner will es mehr glauben. Was tun? Hier kommt in drei Teilen mal ein Auszug aus meinem Buch “Vom Geschäftsprozess zum Workflow” zu dem Thema, wo ich in Anlehnung an Prof. Dr. Winter den Begriff differenziere und versuche möglichst “untechnisch” zu zeigen, was heute (ganz ehrlich!) schon viel bringt, und wo eigentlich noch die ungelösten Schwierigkeiten liegen.

3.3.2 Serviceorientierte Architekturen (SOA)

Im Kontext der Anwendungsintegration ist in jüngerer Zeit ein Paradigma der Softwaretechnik zu großer Popularität gelangt: Das Prinzip der serviceorientierten Architektur (SOA). Ein negativer Nebeneffekt dieses Hypes ist die Ausdehnung des Begriffes auf verschiedenste Problemstellungen, was zu allgemeiner Verwirrung und, daraus resultierend, zum Teil sogar Ablehnung  des Themas geführt hat. Aus diesem Grund soll an dieser Stelle zunächst eine Klärung und Abgrenzung des Begriffes vorgenommen werden.
Diese Klärung orientiert sich an der Differenzierung des SOA-Begriffes, die Prof. Dr. Robert Winter vom

Institut für Wirtschaftsinformatik an der Universität St. Gallen vornimmt [WINTER2007].

Die Darstellung im Bild ist angelehnt an das Business Engineering Framework der Universität St. Gallen, die zwischen fünf Ebenen der Unternehmensarchitektur unterscheidet:

•    Die strategische Ebene bezieht sich auf die grundsätzlichen Geschäftsmodelle des Unternehmens.
•    Die organisatorische Ebene beinhaltet u.a. die Gestaltung sämtlicher Geschäftsprozesse eines Unternehmens, insbesondere mit der Ambition der strategischen Ausrichtung
•    Die Integrationsebene (manchmal auch Agilitätsebene) verbindet Business und IT, indem sie die organisatorischen Anforderungen auf die unter ihr liegende
•    Software-Ebene abbildet. Diese Ebene umfasst sämtliche Anwendungen eines Unternehmens.
•    Die Infrastrukturebene wiederum bezieht sich auf die physische IT, also auf die Computer, Netzwerke, Peripheriegeräte etc.

Während die strategische Ebene aufgrund der steigenden Dynamik in den Märkten mittlerweile alle 1-2 Jahre angepasst werden muss, und die organisatorische Ebene sogar alle 3-6 Monate,  können die Ebenen Software- und Infrastruktur lediglich alle 6-10 Jahre, nämlich im Rahmen umfangreicher IT-Entwicklungs- bzw. IT-Beschaffungsprojekte, angepasst werden. In der Folge ist die IT in vielen Unternehmen ein Risiko für die inzwischen geradezu überlebenswichtige Beweglichkeit geworden. Dieses Agilitätsproblem soll zum Einen durch die Gestaltung der Integrationsebene gelöst werden, und ist zum Zweiten die wesentliche Motivation für das SOA-Paradigma. Allerdings unterscheidet Winter ausgehend vom Business Engineering Framework zwischen drei möglichen Ausprägungen der SOA-Diskussion:

Serviceorientierte Software-Architektur (SOSA)
Das Betrachtungsobjekt eines SOSA-Engagements sind die Anwendungen, die mit technischen Schnittstellen (Software-Services) auszurüsten sind. Diese Services kapseln Anwendungsfunktionalität auf relativ feingranularer Ebene. Hauptambition einer SOSA sind Interoperabilität, also die Fähigkeit zur plattformübergreifenden Zusammenarbeit von Anwendungen, und Wiederverwendbarkeit der Services. Im Business Engineering Framework ist SOSA dementsprechend der Software-Ebene zuzuordnen.

Serviceorientierte Integrations-Architektur (SOIA)
Auf der Integrationsebene spielen sich die Aktivitäten zum prozessorientierten Aufbau einer SOA ab. Hier werden die auf der Software-Ebene umzusetzenden fachlichen Services definiert und auf die Organisationsebene ausgerichtet. Die Gestaltungsziele einer SOIA sind dementsprechend Business-IT-Alignment und Flexibilität der Services.

Serviceorientierte Prozessarchitektur (SOPA)
Die Idee der SOPA ist wiederum die Definition von Services auf Organisationsebene, die durch Unternehmensprozesse umgesetzt werden und somit mit maximaler Effektivität und Effizienz gestaltet sein sollen.

Die von Winter vorgeschlagene Differenzierung ist sehr hilfreich, um die vielen verschiedenen öffentlichen Diskussionen, Vorschläge, aber auch die Kritik zu sortieren und zu bewerten, die sich momentan unter dem allgemeinen Schlagwort „SOA“ abspielen, und um einen nüchternen Abgleich mit der Praxis vorzunehmen.
Dieser nun folgende Abgleich basiert auf den Erfahrungen und Schlussfolgerungen der Autoren dieses Buches und soll somit nicht als Auffassung von Winter oder der Universität St. Gallen dargestellt werden, auch wenn hier möglicherweise Übereinstimmungen existieren.

3.3.2.2 SOSA in der Praxis
Betrachtet man zunächst den Bereich „SOSA“, so stößt man heute bereits auf viele erfolgreiche Praxisprojekte. SOSA ist ein sehr technisches Thema, und schon seit einigen Jahren haben sich die im Bereich der „Web Services“ definierten Standards in der Praxis bewährt. Das Basisprinzip von Software-Services ist das Zusammenspiel von Service-Provider, Service-Consumer und Service-Verzeichnis.

Der Consumer, also eine Anwendung, ruft einen von einem Provider, also einer anderen Anwendung, bereitgestellten Web Service auf (Bild). Der Kanal für diesen Aufruf ist in der Regel HTTP (Hypertext Transfer Protocol), bzw. das verschlüsselte und mit Authentifizierung versehene HTTPS (HTTP Secure). Prinzipiell können aber auch andere Kanäle genutzt werden, wie zum Beispiel SMTP (Simple Mail Transfer Protocol), der auch für den Versand von Emails benutzt wird. Der Provider führt die mit dem Service verbundene Funktion aus und gibt das Ergebnis an den aufrufenden Consumer zurück. Dieser Nachrichtenaustausch basiert häufig, aber nicht zwangsläufig, auf dem sogenannten SOAP-Protocol. Die Beschreibung des Services, die vom Provider veröffentlicht wird und durch den Consumer vor einem Aufruf gelesen werden muss, enthält die „Leistungsbeschreibung“ sowie die notwendigen Parameter, die der Consumer in seiner Anfrage übergeben muss, damit der Service ausgeführt werden kann. Diese Beschreibung wird in WSDL-Dateien bereitgestellt (Web Service Description Language). Beide Standards zur Realisierung von Web Services basieren ihrerseits auf XML. Proportional zur Komplexität der SOA steigt auch die Bedeutung eines Verzeichnisses, das die definierten Services verwaltet, eine sogenannte Service-Registry. Dieses Registry kann von einem interessierten Service-Consumer ähnlich wie ein Telefonbuch benutzt werden, um die Adressen von Services zu ermitteln, die Leistungen bereitstellen, die der Consumer benötigt. Im Kontext von Web Services wurden solche Verzeichnisse anfangs mit Hilfe des ebenfalls XML-basierten Standards UDDI (Universal Description, Discovery and Integration) aufgebaut, der sich jedoch im Gegensatz zu SOAP und WSDL auf breiter Front bislang nicht wirklich durchsetzen konnte.

Mittlerweile existieren viele weitere Standards und Frameworks, die spezielle Aspekte einer Web Services – Architektur adressieren, wie zum Beispiel das Thema Sicherheit. Wesentlich für das Verständnis aus übergeordneter Perspektive ist jedoch lediglich dieses relativ einfache Basisprinzip.
Das Gedanke hinter der SOA-Umsetzung mittels Web Services ist auch Teil des allgemeinen Strebens nach Modularisierung in der klassischen Programmierung, indem Programmlogik in Funktionen oder Methoden zusammengefasst wird, die dann aus verschiedenen anderen Programmteilen heraus aufgerufen werden können. Auch die programmiersprachenübergreifende Modularisierung von Code wird bereits seit Jahrzehnten unternommen – ein relativ bekannter Ansatz ist der bereits 1991 veröffentlichte CORBA-Standard. In der Folge ist das SOA- bzw. SOSA-Paradigma an sich nicht neu, wohl aber die Realisierung mittels Web Services, die sich gegenüber früheren Versuchen wie CORBA auf breiter Front durchsetzen konnte. Diese Differenzierung ist wichtig, um Kritikern begegnen zu können, die SOA zu Unrecht als „alten Wein in neuen Schläuchen“ diskreditieren wollen.

Insgesamt sind die Potentiale und Herausforderungen, die mit reinen SOSA-Projekten verbunden sind, heutzutage weitestgehend erforscht und bekannt, sodass eine umfangreiche Praxisreife erreicht wurde. Das bedeutet nicht, dass  SOSA trivial wäre. Im Gegenteil, der auf Aufbau und Betrieb einer sauberen SOA auf Software-Ebene ist außerordentlich anspruchsvoll und muss von hochgradig kompetenten IT-Architekten verantwortet werden, und es existieren zahlreiche wissenschaftliche und praktische Fachbücher, die sich allein diesem Thema widmen. Der Bezug zum Geschäftsprozessmanagement ist jedoch nicht wirklich vorhanden, denn dieser wird auf der SOIA-Ebene hergestellt. Insofern ist auch die mitunter zu hörende Aussage unsinnig, SOA könne ohne Prozessmanagement nicht effektiv funktionieren – eine SOA auf reiner Software-Ebene kann das sehr wohl.

Thema des nächsten Beitrags: SOIA und SOPA