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.