Service-orientierte Architekturen (SOAs) führen zu einem Paradigmenwechsel: weg von datenzentrierten Systemen hin zu prozessunterstützenden Komponenten. Entlang der Geschäftsprozesse entsteht mit ihnen eine flexible und entkoppelte Anwendungslandschaft. Die einzelnen SOA-Services in ihr müssen fachliche Schnittstellen bieten, die komplexe Anwendungslogik kapseln können, da sich so die vielfältigen Abhängigkeiten zwischen Anwendungen verringern lassen. Ferner müssen die Services robust sein und unabhängig vom jeweiligen Aufrufkontext die gleiche Funktion ausführen können. Ist dies gegeben, lassen sich Services ohne Seiteneffekte auch austauschen, einschließlich externer Services oder Standard- beziehungsweise Fertigsoftware-Services.
Kriterien für den Serviceentwurf
• Grobgranular: Services kapseln Anwendungslogik. Wenige Aufrufe, die viel bewirken, sind besser als viele Aufrufe, die erst zusammen den gewünschten Effekt erzielen.
• Technikneutral: Die Schnittstelle verrät nichts über die eingesetzte Implementierungstechnik und kennt nur fachliche Schlüssel.
• Wiederholbar: Ein mehrmaliger Aufruf mit denselben Parametern hat denselben Effekt wie ein einmaliger Aufruf. So richtet ein versehentlich angestoßener zweiter Aufruf kein Unheil an. Wiederholbare Services erhöhen die Stabilität der Anwendungen.
• Atomar: Services werden stets als Transaktionen ausgeführt. Anwendungsübergreifende Transaktionen koppeln Anwendungen zu eng aneinander, was dem Prinzip der losen Kopplung widerspricht.
• Zustandslos: Der Service reagiert auf alle Aufrufe gleich. Der Nutzer stellt die Verbindung zwischen den Service-Aufrufen her, nicht der aufgerufene Service.
Hier lesen Sie …
• wie sich Services finden und entwerfen lassen;
• welche Designprinzipien zu beachtet sind;
• wo die Serviceorchestrierung Probleme macht.
Beim Aufbau von Services können bewährte Konzepte des Anwendungsdesigns helfen, wobei jeder Service fünf Eigenschaften aufweisen muss: Er ist grobgranular, technikneutral, wiederholbar, atomar und zustandslos. So reduzieren grobgranulare Services die Anzahl der Serviceaufrufe und kapseln komplexe Anwendungslogik für die Servicenutzer. Das macht die Interaktion zwischen Anwendungen übersichtlicher. Zum Beispiel kann das Anlegen, Löschen und Ändern von Kunden in einem grobgranularen Service "aendereKunde" zusammengefasst werden. Der Service entscheidet, welche der drei Aktionen in Gang gesetzt werden muss, und sichert über Duplikaterkennung ab, dass ein Kunde nicht mehrfach geführt wird.
Information Hiding
Sind Services technikneutral, dann kapseln sie die Implementierung. Dies entspricht dem Information-Hiding-Prinzip auf Ebene der Anwendungsinteraktion. Servicenutzer und Serviceanbieter werden entkoppelt, indem nur fachliche Schlüssel und Informationen, aber keine technischen Schlüssel ausgetauscht werden. Sind Services wiederholbar, führt dies zu robusteren Anwendungen. Auch wenn der Service "aendereKunde" mehrmals mit denselben Daten aufgerufen wird, bleibt die hinterlegte Information über den Kunden identisch - die Kundendatenhaltung verhält sich fehlertolerant gegenüber dem erneuten Aufruf. Die Anwendungslogik muss sicherstellen, dass sie auf den erneuten Aufruf korrekt reagiert, beispielsweise indem eine Überweisung zwischen zwei Bankkonten nur einmal erfolgt. Dies lässt sich in diesem Fall durch Duplikatschecks sicherstellen.
Umkehrservices
Atomar bedeutet, dass Services entweder vollständig oder gar nicht ablaufen und der alte Zustand bestehen bleibt. Diese Eigenschaft ist in der Regel einfach zu realisieren, indem der Service selbst transaktional implementiert wird. Problematisch wird es beim Zusammenspiel verschiedener Services. Solange alle fehlerfrei laufen, gibt es keine Probleme. Ebenso lässt sich der gesamte Ablauf wiederholen, wenn alle Services fehlschlagen. Funktionieren aber nur einzelne Services nicht, ist eine komplexe Fehlerbehandlung nötig.
Umkehrservices können dieses Problem lösen, indem sie alle Änderungen eines Serviceaufrufs rückgängig machen. Geschäftsprozesse kommen ohne sie normalerweise nicht aus. Daher sollten sie stets bei der Serviceimplementierung und Planung berücksichtigt werden. Fehlen Umkehrservices, müssen Unternehmen zur Problembehandlung Fehlerarbeitsplätze schaffen. Dies ist ein probates Mittel, solange es Einzelfälle bleiben. Atomare Services bieten zudem Vorteile, wenn es um die Interaktion verschiedener Anwendungen geht: Schlägt ein Aufruf fehl, muss der Servicenutzer nicht wissen, ob die Serviceimplementierung oder die Kommunikation die Ursache war. Ein erneuter Aufruf des Service behebt das Problem.
Die Forderung, dass Services zustandslos sein müssen, hat schließlich den Effekt, dass sie ein einheitliches Verhalten an den Tag legen. Der Kontext, in dem ein Service genutzt wird, hat keinen Einfluss auf die Änderung, die er bewirkt. Seiteneffekte beim Aufruf von Services sind somit ausgeschlossen. Zustandslose Services können zudem von mehreren Anwendungen oder mehreren Instanzen einer Anwendung parallel angeboten werden. Dadurch sind die Services einfach skalierbar.
Vorsicht bei externen Services!
Häufig werden SOAs mit dem Argument vermarktet, dass sie Services externer Anbieter integrieren oder diese über Standard- und Fertigsoftware abbilden können. Dies ist grundsätzlich auch richtig, allerdings kann die Integration solcher Services in der Einführungsphase den Gesamterfolg eines SOA-Projekts gefährden. Grund hierfür ist, dass Anwender sich zu sehr mit der technische Integration der externen Systeme beschäftigen und darüber die fachliche Gestaltung der Anwendungslandschaft und ihrer Services vernachlässigen. Ohne erkennbaren fachlichen Nutzen lassen sich die Investitionen in die SOA aber nicht begründen, und es wird keine Akzeptanz im Unternehmen erreicht.
Wollen Unternehmen ihre Services orchestrieren, so sollte dies technisch kein großes Problem mehr sein. Hierzu gibt es heute Prozess-Engines und Modellierungs-Tools die etablierte Standards wie die Web Services Business Process Execution Language (WS-BPEL) unterstützen. Aber es gibt noch offene Punkte: Wie werden beispielsweise durch die Engine laufende Prozesse nach technischen Problemen wieder aufgesetzt, ohne dass es zu einem inkonsistenten Systemzustand kommt?
Auch ist das Versprechen der Hersteller, dass auch weniger versierte Mitarbeiter aus den Fachbereichen mit ihren Produkten Prozesse entwerfen können, bis heute meist eine schöne Vision. Zwar sind für den Prozessentwurf tiefe Kenntnisse einer Programmiersprache nicht mehr zwingend erforderlich, aber er verlangt eine gute Übersicht über das Serviceportfolio des Unternehmens. Erst durch dieses Wissen lassen sich die richtigen Services für bestimmte Geschäftsprozesse entwerfen. Zusätzlich ist die fundierte Erfahrung in der IT-Prozessgestaltung ein wichtiger Erfolgsfaktor.
Orchestrierung
Services und die Prozess-Engine laufen in der Regel in unterschiedlichen Systemprozessen ab. Jeder Aufruf eines Service bringt daher Systemprozesswechsel mit sich. Entscheidend für eine tragfähige Architektur ist daher auch richtiges Augenmaß beim Prozessdesign.
Eine Serviceorchestrierung kann ferner nur dann einen Mehrwert stiften, wenn bereits eine hinreichend große Anzahl von Services existiert und diese sich in der Anwendungslandschaft etabliert haben. Serviceorchestrierung ist zudem nicht nur ein technisches, sondern auch ein politsches Thema. So erfordern die auf Basis eines Standards modellierten Prozesse ein Prozesswissen, das bislang meist der Entwicklungsabteilung vorbehalten war. Dies kann zu Widerständen gegen den Verlust des Wissensmonopols führen und der Idee der Orchestrierung entgegenlaufen. Unternehmen sollten daher schrittweise vorgehen und zunächst einige, wenige Prozesse, die häufig und flexibel geändert werden müssen, auswählen. (as)