Wie SOA-Dienste hochverfügbar werden

In einer SOA können Services von unterschiedlichen Geschäftsprozessen wiederverwendet und kombiniert werden. Eine IT auf Basis von SOA bietet den Geschäftsprozessen damit die für den Geschäftsbetrieb so wichtige und immer wieder geforderte Flexibilität, und das bei richtigem Einsatz auch zu niedrigen Kosten. Unabhängig davon bleibt die Verfügbarkeit der IT-Leistungen auf dem benötigten Qualitätsniveau natürlich wichtig. Besonders in einem dynamischen Geschäftsumfeld, dessen IT ständig an neue Geschäftsanforderungen angepasst werden muss und deshalb auf SOA setzt, müssen IT-Dienstleistungen - trotz oder gerade wegen ihrer Flexibilität - stabil und kontinuierlich bereitgestellt werden.

Für den Aspekt Hochverfügbarkeit sind drei Faktoren bei einer SOA besonders wichtig:

Faktor 1: Architektonische Eigenschaften

Damit die Leistungserbringung eine stabile Basis besitzt, müssen auch bei der Architektur einige Punkte berücksichtigt werden. Die Architektur einer SOA hat im Wesentlichen vier Ebenen (siehe Grafik).

Auf der untersten Ebene "Infrastruktur" befinden sich die klassischen Infrastrukturkomponenten wie Server, Datenbanksysteme und das Netzwerk. Hinsichtlich Hochverfügbarkeit ändert sich in dieser Ebene nichts. Für eine hochverfügbar ausgelegte Anwendung muss auch die Infrastruktur, auf der die Anwendung läuft (insbesondere das Netzwerk) hochverfügbar ausgelegt sein. Dies gilt auch in einer SOA und soll an dieser Stelle nicht weiter vertieft werden.

Die SOA-Services innerhalb der nächsten Ebene "Services" stützen sich auf die Infrastrukturebene. Im Vergleich zu klassischen Anwendungen sind diese Services in der Regel funktional kleiner und besser abgrenzbar. Damit ist die Erfüllung der Hochverfügbarkeitskriterien der Services einfacher zu messen und sicherzustellen. Die feinere Granularität vereinfacht es auch, bestimmte Services auf Hochverfügbarkeit zu trimmen (siehe auch: Wie granular müssen SOA-Services sein?).

Die nächste Ebene "Kommunikation und Transaktion" besteht aus SOA-spezifischen Komponenten. Als wichtigste Komponenten für den produktiven Betrieb sind auf dieser Ebene der Enterprise Service Bus (ESB) und die SOA-Registry zu nennen. Der ESB steuert die Verarbeitung und Kommunikation zwischen den einzelnen, in der SOA-Registry registrierten Services. Mit dem ESB wird die Kommunikation zwischen Aufrufer und aufgerufenen Services entkoppelt (man spricht von loser Kopplung). Der ESB nimmt Anfragen entgegen und hat einen Service zu finden, der den funktionalen - aber auch nicht-funktionalen - Spezifikationen des Aufrufers genügt. Als Bindeglied zwischen Geschäftsprozessen und den sie erbringenden Services muss der ESB mindestens so verfügbar sein wie der Service mit den höchsten Verfügbarkeitsanforderungen. Entsprechend sind die Verfügbarkeitsanforderungen an den ESB meist sehr hoch. Die SOA-Registry muss je nach Nutzung ebenso hochverfügbar wie der ESB ausgelegt werden.

Auf der Ebene "Kommunikation und Transaktion" ermöglicht eine SOA eine Reihe von neuen Mechanismen, die eine Hochverfügbarkeit unterstützen:

• Services können mehrfach instanziiert werden und/oder topologisch "näher" an die Leistungsabrufer verteilt werden. Hierdurch kann relativ einfach die Ausfallwahrscheinlichkeit reduziert, der Durchsatz erhöht (Load-Balancing) und Antwortzeiten durch weniger Latenzzeiten verkürzt werden.

• Serviceaufrufe können auf unterschiedliche Versionen und/oder Systemumgebungen desselben Services umgeleitet werden. Bei einem Release-Wechsel lässt sich der veränderte Service mit ausgewählten "Live"-Szenarien testen und schnell zwischen Versionsständen umschalten.

• Der ESB kann Überwachungsdienste bereitstellen, die Hochverfügbarkeitskriterien bei den Services (zum Beispiel Antwortzeit, Aufruffrequenz) messen und kritische Ereignisse an ein Event Management weiterleiten.

Auf der Ebene "Orchestrierung und Komposition" werden die Services gemäß der benötigten geschäftsprozessspezifischen Logik zusammengestellt. Hier stellen sich dieselben Herausforderungen, wie sie sich auch schon bei herkömmlichen Anwendungen zeigen: In der Theorie sichert die Verfügbarkeit aller Einzelkomponenten auch die Verfügbarkeit der gesamten Leistung. In der Praxis sorgen Lücken in der Planung und Umsetzung aber immer wieder für Ausfälle einzelner Services, weshalb das End-to-End Monitoring hier immer bedeutungsvoller wird. Die Tatsache, dass Services dynamisch in unterschiedlichen Geschäftstransaktionen verwendet werden können, bedingt ein übergreifendes Monitoring mit entsprechender Dynamik unter Erhaltung des Kontextes des konkreten Geschäftsvorfalls unter dem ein Service aufgerufen wurde.

Faktor 2: Höhere Verfügbarkeitsanforderungen bei gleichzeitig höherer Änderungsfrequenz

Durch den vermehrten Einsatz moderner Technologien und Dienstleistungen für global verteilte Märkte nehmen die Anforderungen an die Verfügbarkeit der Geschäftsprozesse zu. Es ist aber davon auszugehen, dass die Verfügbarkeitsanforderungen innerhalb einer SOA im Vergleich zu herkömmlichen Architekturen per se höher sind:

• Durch die gemeinsame Nutzung von Services in mehreren Geschäftsprozessen summieren sich die individuellen Anforderungen an die Verfügbarkeit aller beteiligten Services. Ist ein Geschäftsprozess hochverfügbar auszulegen, so müssen auch alle Services, die diesen Geschäftsprozess erbringen, übergreifend den entsprechenden Hochverfügbarkeitskriterien genügen. Dies gilt auch für Services, die im Kontext anderer Geschäftsprozesse nicht hochverfügbar ausgelegt zu sein bräuchten.

• Überlappen sich die Betriebszeiten von Geschäftsprozessen, erweitert sich auch der Zeitraum, in der die gemeinsam genutzten Services hochverfügbar sein müssen.

• Die gesamte SOA-Infrastruktur mit den Systemen, auf denen SOA-Komponenten wie ESB und SOA-Registry implementiert sind, muss zusätzlich gesichert werden.

Höhere Verfügbarkeitsanforderungen bedeuten letztendlich aber, dass - wenn überhaupt - nur mehr sehr kurze Unterbrechungen erlaubt und Wartungsfenster für Änderungen damit u.U. nicht mehr möglich sind. Aber gerade die Häufigkeit von Änderungen ist wegen der benötigten Flexibilität in einer SOA erwartungsgemäß hoch. Eine SOA ist gerade für solche Unternehmen interessant, in denen die IT agil auf ein dynamisches Geschäftsumfeld reagieren können muss. Im Umkehrschluss kann man also davon ausgehen, dass sich die Geschäftsdynamik in einer IT auf Basis einer SOA in Form von häufigen Änderungen tatsächlich auch manifestiert.

Faktor 3: Erhöhte Dynamik durch Kombination und Wiederverwendung von Services

Services in einer SOA sind nach funktionalen aber auch nach nicht-funktionalen Gesichtspunkten entworfen, darunter Kriterien wie Verlässlichkeit, Stabilität und Antwortzeit. Während sich die Anforderungen an die Verfügbarkeit im Lebenszyklus einer herkömmlichen Anwendung selten bis nie ändern, muss bei einem Service, immer wenn ein weiterer Geschäftsprozess diesen verwendet, geprüft werden, ob er die Verfügbarkeitsanforderungen des neuen Verbrauchers erbringen kann. Eventuell müssen in diesem Zusammenhang ein Service einer neuen Verfügbarkeitsklasse zugeordnet und entsprechend mehr Vorsorgemaßnamen bereitgestellt werden. Dasselbe gilt umgekehrt, wenn sich ein Geschäftsprozess von einem Service abmeldet und beispielsweise Hochverfügbarkeitsmaßnahmen für den Service damit nicht mehr notwendig sind.

Aufgrund dieser drei Faktoren ergeben sich für die Umsetzung eines adäquaten Verfügbarkeitsniveaus in einer SOA folgende Postulate:

• Es ist sicherzustellen, dass die genannten architekturinhärenten Mechanismen/Vorteile für Hochverfügbarkeit genutzt werden.

• Effektivität, Kosteneffizienz und Verfügbarkeitsanforderungen sind sowohl im Rahmen der Entwicklung, als auch im Betrieb laufend zu messen und mit den definierten Anforderungen der Geschäftsprozesse abzugleichen.

• Die Dynamik in einer SOA muss mit Hilfe von SOA-Administrations-Tools effektiv steuerbar sein.

Daraus leiten sich die eigentlichen Herausforderungen bei der Umsetzung eines Hochverfügbarkeitsniveaus in einer SOA ab.

Herausforderung 1: Aufteilung der Services nach Hochverfügbarkeitskriterien

Der Service-Schnitt muss unter Berücksichtigung von Hochverfügbarkeitskriterien konzipiert bzw. optimiert werden:

• Hochverfügbarkeitsmaßnahmen dürfen nur für diejenigen Elemente bereitgestellt werden, an die entsprechende Anforderungen gestellt werden. Es muss deshalb eine geeignete Aufteilung der Services in Verfügbarkeitsklassen in einer Granularität gefunden werden, die eine hinreichend scharfe Abgrenzung bei vertretbaren Kosten erlaubt.

• Es müssen Systemkonfigurationen, Vorsorgemaßnahmen und Überwachungsmaßnahmen für unterschiedliche Aspekte von Hochverfügbarkeit definiert und bereitgestellt werden. Services, die sehr performant sein müssen, sind auf Systemen mit hoher Rechenleistung zu betreiben, Cluster sind für Services notwendig, die eine geringe Ausfallwahrscheinlichkeit benötigen. Durch die Spezialisierung der Systemkonfigurationen können Kosten gespart werden.

• Die Services müssen hinreichend schlank sein, so dass SOA-spezifische Mechanismen wie "Klonen" sinnvoll genutzt werden können. Beispielsweise ist das Klonen von Services meist nicht kosteneffektiv wenn es sich um eine komplexe, gekapselte Anwendung handelt, da die gesamte Anwendungsinfrastruktur eventuell doppelt bereitgestellt werden muss.

Herausforderung 2: Hochverfügbarkeit im ESB (Kommunikationsebene)

Der ESB muss befähigt werden, auf Basis von nicht-funktionalen Kriterien, die der Aufrufer vorgibt (zum Beispiel Antwortzeit), die Anfragen an denjenigen Service weiterzuleiten, der die Hochverfügbarkeitskriterien erfüllen kann. Dazu müssen einerseits die entsprechenden Metadaten für solche nicht-funktionalen Kriterien im Repository für jeden Service hinterlegt werden. Der ESB kann so entscheiden, zu welchem konkreten Service eine Anfrage geroutet werden muss, damit die Hochverfügbarkeitsanforderungen des aufrufenden Geschäftsprozesses erfüllt werden.

Andererseits muss ein Messsystem mit geeigneten Messpunkten gefunden werden, mit denen aktuelle Verfügbarkeitsdaten (Antwortzeit, Durchsatz, Ausfallzeit, Aufruffrequenz etc.) sowie verfügbare Kapazitäten gemessen werden können. Diese Informationen muss der ESB nutzen, etwa durch Umleitung von Anfragen an einen alternativen Service, sofern absehbar ist, dass ein überlasteter Service die Anfrage nicht mehr innerhalb der zugesicherten Zeit bearbeiten kann.

Die Überwachung von einzelnen Services stellt dabei im Allgemeinen keine besondere Herausforderung dar. Die große Herausforderung liegt vielmehr darin, dass eine Überwachung auch immer den Kontext des konkreten Geschäftsvorfalls berücksichtigen muss, in welchem ein Service ausgeführt wird. Der Bedarf an einem solchen End-to-End Monitoring von Geschäftsvorfällen über alle seine erbringenden Services stellt eine große Herausforderung innerhalb einer SOA dar. Überwachungsdienste im ESB müssen demzufolge so ausgelegt sein, dass sie dieses End-to-End Monitoring im Kontext eines Geschäftsvorfalls unterstützen.

Herausforderung 3: Dynamik im Griff behalten

Natürlich müssen alle Veränderungen an der bereitgestellten Infrastruktur und der Kommunikationsebene über ein Change Management verwaltet werden. Aber auch die Veränderungen, die sich aus der Umsetzung und Nutzung der Geschäftsprozesse ergeben, müssen überwacht werden.

Die eigentlichen Herausforderungen liegen dabei in der Kontrolle und Steuerung

• der Dynamik, in der Services in unterschiedlichen Geschäftsprozessen eingesetzt werden. Es muss sichergestellt werden, dass immer bekannt ist, welche Services welche Geschäftsprozesse unterstützen;

• der Veränderungen an die Verfügbarkeitsanforderungen jedes Services, bedingt durch funktionale Änderungen oder Verwendung des Services in neuen oder anderen Geschäftsprozessen und

• der Dokumentation der Verfügbarkeitskriterien, die ein Service tatsächlich leisten kann.

Nur dann ist das Change Management in der Lage sicherzustellen, dass immer das notwendige Verfügbarkeitsniveau jedes einzelnen Services bereitsteht, ohne dass die Kosten hierfür explodieren.

Umsetzung von Hochverfügbarkeit in einer SOA

Berücksichtigt man die genannten Herausforderungen, dann lässt sich Hochverfügbarkeit in einer SOA zu vernünftigen Kosten betreiben, und das trotz verschärfter Verfügbarkeitsanforderungen und erhöhter Dynamik einer SOA. Die Schritte für ein entsprechendes Vorgehen werden im Folgenden beschrieben. Das Vorgehen ist im Wesentlichen unabhängig davon, ob eine SOA neu aufgebaut oder eine bestehende SOA optimiert werden soll.

Schritt 1: Definition von Verfügbarkeitsklassen und den dafür eingesetzten Infrastrukturkomponenten

Neben rein funktionalen Erwägungen muss auch das zu erwartende Mengenmodell und die geforderte Verfügbarkeit bei der Festlegung der Serviceschnitte berücksichtigt werden. Auf der Basis der Infrastrukturarchitekturentscheidung sind Verfügbarkeitsklassen zu definieren und bei der Anforderungsdefinition entsprechend anzuwenden. Je nach Unternehmen ist die sinnvoll zu definierende Anzahl von Klassen unterschiedlich. Es hat sich jedoch gezeigt, dass es wenig sinnvoll ist, mehr als fünf Verfügbarkeitsklassen für Services zu definieren. Ein Kriterienkatalog erlaubt die Auswahl der benötigten Verfügbarkeitsklasse und damit die automatische Auswahl der in dieser Klasse vordefinierten Infrastrukturkomponenten (zum Beispiel Cluster).

Schritt 2: Bündelung von Services nach Hochverfügbarkeitskriterien

Im zweiten Schritt ist es notwendig, eine geeignete Bündelung der benötigten Services in unterschiedliche Verfügbarkeitsklassen zu finden. Nur so ist es später möglich, Hochverfügbarkeitsmaßnamen gezielt für die Services zu planen, die diese auch tatsächlich benötigen. Neben rein funktionalen Anforderungen spielt bei der Auswahl der geeigneten Zusammenstellung das Kosten-Mengenmodell der zu liefernden Services und der zugrundeliegenden Transaktionen vor dem Hintergrund der benötigten Verfügbarkeitsklasse eine entscheidende Rolle (siehe Grafik Kosten-Mengenmodell).

Begonnen wird mit einer ersten groben Einordnung der Services in Verfügbarkeitsklassen. Jeder Service, der gemäß dieser Einteilung hochverfügbar sein muss, wird in seine Funktionen zerlegt. Identifiziert man dabei Funktionen, die nicht hochverfügbar sein müssen, hat man eine mögliche Aufteilung des Service gefunden. Für die hochverfügbaren Funktionen kann man die Rekursion auf Transaktions- oder Aufrufebene wiederholen. Sollte sich dabei beispielsweise herausstellen, dass eine Transaktion besonders häufig aufgerufen wird, ist es eventuell sinnvoll diese Transaktion zukünftig als eigenen Service bereitzustellen. Wichtige Basis für diese Entscheidung liefert das im ersten Schritt ausgearbeitete Mengenmodell.

Grundsätzlich kann man dies für die abgestuften Verfügbarkeitsklassen wiederholen. Da Maßnahmen für Hochverfügbarkeit jedoch teuer sind, wird mit der Bündelung von hochverfügbaren Funktionen/Transaktionen der größte Mehrwert erzielt. Eine sehr detaillierte Analyse von Services niedriger Verfügbarkeitsklassen ist angesichts des Kosten-Nutzen-Verhältnisses meist nicht sinnvoll. Auch bei dieser Entscheidung ist das Mengenmodell aus dem ersten Schritt maßgebend.

Bei der anschließenden Bündelung von Funktionen/Services ist Folgendes zu berücksichtigen:

• Funktionale Kriterien und logische Zusammengehörigkeit von Services und auch die Hintergründe für eine eventuelle bestehende Bündelung von Services.

• Kosten für ein "Herauslösen" von Funktionen/Transaktionen in eigene Services (siehe Mengenmodell). Eine "logische" Bündelung von Services kann sich als kostengünstiger darstellen. Dabei werden nicht mehrere funktional unterschiedliche Services erzeugt, sondern "nur" ein Service mehrfach - etwa mit unterschiedlichen Aufrufsignaturen -instanziiert. Der ESB übernimmt dann das Routing je nach aufgerufener Signatur.

• Das Zusammenspiel zwischen Services, insbesondere zwischen internen Services und extern erbrachten Leistungen.

Schritt 3: Planung und Umsetzung von Hochverfügbarkeitsmaßnahmen

Auf Grundlage der beiden vorherigen Schritte wird ein Konzept ausgearbeitet, das beschreibt, wie die gefundene oder optimierte Service-Struktur und die einzelnen Verfügbarkeitsmaßnahmen umgesetzt werden sollen. Dieses Konzept beschreibt:

• welche Services wie angepasst werden oder welche Bündel von Funktionen als eigene Services implementiert werden,

• die Spezifikation der Leistungsdaten eines Services (maximaler Durchsatz, maximale Antwortzeit etc.),

• die Verteilung der Services auf unterschiedliche SOA-Umgebungen und/oder Systemkonfigurationen,

• die Service-Instanzen und das Routing,

• die konkreten Verfügbarkeitsmaßnahmen für die einzelnen Verfügbarkeitsklassen und

• das Monitoring und Metering gemäß dem definierten Mengenmodell.

Umgesetzt wird das Konzept parallel zum letzten Schritt

Schritt 4: Change Management anpassen

Die Hauptaufgabe in diesem Schritt ist es, zwei Prozesse in das Change Management zu integrieren, die sicherstellen, dass der Prozess die Hoheit über die Dynamik in einer SOA behält:

1. Einen Registrierungsprozess für die im Rahmen der Orchestrierung verwendeten Prozesse. So ist jederzeit nachvollziehbar, welche Kombinationen aus Geschäftsprozessen und den von ihnen genutzten Services im Einsatz sind. Der Prozess stellt sicher, dass Implikationen auf Verfügbarkeit und Verfügbarkeitsmaßnahmen adäquat behandelt werden, wenn sich ein Geschäftsprozess von einem Service an- oder abmeldet.

2. Einen Katalogisierungsprozess, der sicherstellt, dass für jeden Service dokumentiert ist, welcher Verfügbarkeitsklasse er zugehört und welche Hochverfügbarkeitskriterien er aktuell oder maximal leisten kann. Dieser Prozess stellt also sicher, dass diese Informationen über ein SOA-Repository oder über selbstdokumentierende Services aktuell bleiben und abgefragt werden können.

Die beschriebenen vier Schritte müssen in der Praxis regelmäßig erneut durchgeführt werden, denn im Sinne einer kontinuierlichen Verbesserung und im Kontext sich ändernder Geschäftsanforderungen ist das definierte Mengenmodell und Design regelmäßig zu hinterfragen.

Zusammenfassung

SOA ist ein vielbeschriebenes neues Paradigma mit dem sich große Effizienz und Agilität bei der IT-Leistungserbringung erzielen lassen. Mit der Bündelung von zentralen Geschäftsfunktionen steigen die ohnehin schon hohen Anforderungen an die Systeme noch weiter an. Mit einer Mischung aus bekannten Verfahren und neuartigen SOA-spezifischen Designkriterien lassen sich die Aufwendungen für die Bereitstellung hochverfügbarer Services minimieren. Dazu werden nur genau die Dienste in einer entsprechenden hochverfügbaren Umgebung betrieben, die tatsächlich hohen Verfügbarkeitsanforderungen genügen müssen. Damit können die entstehenden Kosten reduziert werden, was die Attraktivität von SOA-Umgebungen weiter steigert. (wh)

Mehr zum Thema SOA im CW-Experten-Blog SOA meets BPM.