Typische Anwendungsmuster

In der Integrationslandschaft der Union Investment finden sich vor allem drei Anwendungsmuster:

• Replikation von Daten zwischen heterogenen Systemen, verbunden mit Datenmapping und hohen Anforderungen an Performance und Transaktionssicherheit. Häufig werden Daten für die Verteilung zwischen mehreren Zielsystemen oder zur Trennung von Transaktionen in einem Messaging-System abgelegt.
• Synchroner Aufruf von Methoden in zustandslosen Services mit hohen Anforderungen an die Parallelisierbarkeit und möglichst kurzen Antwortzeiten.
• Workflow-Module mit eigener Persistenz zur Implementierung lang laufender Prozesse in mehreren Instanzen.

Alle diese Anwendungsmuster lassen sich auf der ServiceMix/JBoss-Infrastruktur perfekt abbilden.

Datenbankschnittstellen

Viele Schnittstellen der Integrationsarchitektur erforden die Analyse der Inhalte von Datenbanktabellen auf Änderungen hin und das Spiegeln dieser Änderungen in verschiedenen Zieldatenbanken. Die RDBMS-Binding-Komponente greift dazu periodisch auf die Quelldatenbank zu und ermittelt die geänderten Datensätze. Das kann durch Abfrage eines Änderungszeitstempels geschehen oder dadurch, dass die Ausgangstabelle mithilfe eines Triggers eine Zwischentabelle füllt, aus der sich die geänderten Datensätze destruktiv auslesen lassen.

Grundsätzlich erzeugt die Binding-Komponente ein standardisiertes XML-Format, das die Inhalte in datenbankunabhängiger Form beinhaltet, aus der sich beim Schreiben in eine Zieldatenbank die SQL-Anweisungen in Abhängigkeit vom Dialekt der Zieldatenbank erzeugen lassen.

JMS Messaging

Die meisten JMS-Messaging-Systeme verwenden als Persistenzschicht eine relationale Datenbank. Die Union IT-Services GmbH setzt eine Oracle-Datenbank ein, in der JBossMQ – die JMS-Implementierung des JBoss-Servers – seine Daten ablegt. Die Hauptlast für die Datenbank entsteht dabei durch das Lesen und Schreiben von BLOBs, wobei der Durchsatz wesentlich von der Größe der Nachrichten abhängt. Da die Performance der Datenbank entscheidend ist, unterscheiden sich die meisten JMS-Implementierungen hinsichtlich ihres Durchsatzes nur unwesentlich.

Die Standardkonfiguration von JBossMQ sieht eine Dead Letter Queue (DLQ) vor. Tritt während der Verarbeitung einer Nachricht eine Exception auf, stellt JBossMQ die Nachricht in die DLQ, um die nächste Nachricht auf der Queue bearbeiten zu können.

Für eine Integrationslösung ist dieses Verhalten allerdings nicht akzeptabel, weil häufig fehlerhafte Quelldaten die Ursache von Verarbeitungsfehlern sind. In diesem Fall darf die Weiterverarbeitung der Queue erst nach der Bereinigung der Quelldaten erfolgen – sonst könnten etwa die Daten für Kontotransaktionen die eigentliche Kontoeröffnung überholen.

Applikationsbetrieb

Im produktiven Betrieb der gesamten Plattform müssen die Integrationsplattform und die SOA lückenlos überwacht und möglichst automatisiert gesteuert werden. Dazu gehören unter anderem:

• automatischer Start und Stopp von einzelnen Anwendungen etwa nach der Uhrzeit;
• Neustart von Anwendungen, die ihre Ausführung wegen Fehlfunktionen der Randsysteme automatisch gestoppt haben;
• automatische Umschaltung von lasterzeugenden Anwendungen auf weniger belastete Rechner;
• kontinuierliche Überprüfung vitaler Funktionen wie Speicherverbrauch, CPU-Last und Plattenplatz;
• Funktionstests der Randsysteme, um Ausfälle frühzeitig zu erkennen.

Dazu gehört auch die Benachrichtigung des Betriebspersonals durch E-Mail und SMS. Da Ausfälle im Minutenbereich bereits zu erheblichen Schäden führen können, ist die schnelle Information und Reaktion von essentieller Bedeutung.

Automatische Steuerung

Die automatische Steuerung des Systems können die laufenden Application Server selbst übernehmen. Dazu wurde ein JBoss-Service entwickelt, dessen Datenmodell den Sollzustand der aktiven Anwendungen enthält. Das Datenmodell erlaubt dabei die Konfiguration des gewünschten Status (gestartet und angehalten) sowie die Parametrisierung von Betriebszeiten, was es ermöglicht, eine Anwendung beispielsweise nur zu bestimmten Uhrzeiten, Wochentagen, Arbeits- oder Feiertagen laufen zu lassen.

Das Datenmodell erlaubt den Abgleich des Soll-Zustands mit dem über JMX-Funktionen festgestellten Ist-Zustand. Treten Abweichungen auf, versucht der Service, den Soll-Zustand durch Starten oder Stoppen der Anwendungen zu erreichen.

Überwachung

Unabhängig davon, dass sich die Komponenten im Soll-Zustand befinden müssen, efolgt eine Überwachung der Abnahme- und Produktionsumgebung mit dem Open-Source-Monitoring-Tool Hobbit in Version 4.

Der Zustand des Systems lässt sich permanent überwachen.

Der Hobbit-Server verfügt über ein Web-Frontend, das diverse Agenten auf den zu überwachenden Systemen mit Messwerten wie CPU-Last, Plattenplatz, Speicherauslastung und so weiter versorgen. Zusätzlich kann beim Überschreiten von Schwellenwerten eine automatische Benachrichtigung ausgelöst werden.

Speziell entwickelte Agenten überwachen die JBoss/ServiceMix-Umgebungen direkt und erheben zusätzliche Daten. So zeigen die Response-Zeiten auf der Service-orientierten Architektur nicht nur Trends auf, sondern erlauben auch eine einfache Überwachung der durch das Service Level Agreement definierten Antwortzeiten.