Mission Critical IT

Wie SOA-Dienste hochverfügbar werden

23.10.2008
Von Andreas Knaus und Thomas Höller
Wenn SOA-Umgebungen zentrale Geschäftsprozesse unterstützen, müssen IT-Verantwortliche auch einzelne Services hochverfügbar bereitstellen. Dabei sind einige Regeln zu beachten.

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).

Hochverfügbarkeit muss auf allen Ebenen einer Service-orientierten Architekur sichergestellt werden.
Hochverfügbarkeit muss auf allen Ebenen einer Service-orientierten Architekur sichergestellt werden.

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.