Oswald Regular
OpenSans Regular
Continuous>Flows®

Die Echtzeitverarbeitung von Geschäftsdaten ist mit großen Herausforderungen verbunden, und nur wenige Softwareprodukte packen sie an. Ab Initio®-Software ist hier die Ausnahme.

Ab Initio-Software wird für eine Vielzahl unterschiedlichster Echtzeitanwendungen eingesetzt, von Minibatch über asynchrones Messaging mit großen Datenmengen und serviceorientierte Anwendungen (SOA) bis hin zu Request-/Response-(Anfrage-/Antwort)-Anwendungen mit kurzer Latenzzeit. Hierbei kommt stets dieselbe Technologie zum Einsatz: das Continuous>Flows®-Software-Paket des Co>Operating Systems.

Das Co>Operating System® ist eine „Datenfluss-Engine“. Diese Engine befördert Datensatz- oder Transaktionsströme durch eine Sequenz von „Komponenten“. Diese Komponenten führen eine Vielzahl von Berechnungen an den Eingabedatensätzen durch, beispielsweise indem durch Anwenden von Geschäftsregeln Ausgabedatensätze erstellt werden. Komplexe Verarbeitungslogik wird in leicht verständliche Schritte zerlegt, die jeweils von einer anderen Komponente ausgeführt werden. Hierbei fließen Datensätze durch die erforderlichen Komponenten, bis die Verarbeitung abgeschlossen ist.

Dieses Datenflussmodell ist sowohl für die Batchverarbeitung als auch für die Echtzeitverarbeitung ideal geeignet. Auch wenn eine Batchanwendung der entsprechenden Echtzeitanwendung stark ähneln kann, unterscheiden sich Batch- und Echtzeitanwendungen in ihren Endpunktkomponenten. Während Batchanwendungen mit flachen Dateien und statischen Datenbanktabellen-Komponenten verbunden sind, sind Echtzeitanwendungen mit Message-Queues, Web-Services, RPCs, CICS-Servern und/oder Spezialkomponenten verbunden (üblicherweise über TCP/Sockets).

Beim Arbeiten mit Ab Initio-Software führt die Tatsache, dass Batch- und Echtzeitanwendungen große Gemeinsamkeiten aufweisen und eine einheitliche Technologie nutzen – nämlich das Co>Operating System –, zu einer wesentlich geringeren Komplexität und einer deutlich höheren Leistung. Die geringere Komplexität wiederum führt zu einer höheren Produktivität und die höhere Leistung reduziert die Kosten.

Wiederverwendbarkeit der Geschäftslogik zwischen Batch- und Echtzeitanwendungen

In den meisten Fällen bleiben die Geschäftslogikkomponenten zwischen den Eingabe- und Ausgabekomponenten unverändert, sodass die gleiche Geschäftslogik zwischen Batch- und Echtzeitanwendungen wiederverwendet werden kann. Dies hat große Auswirkungen auf die Produktivität. Bei den Ansätzen anderer Anbieter werden für die Batchverarbeitung und die Echtzeitverarbeitung üblicherweise ganz unterschiedliche Technologien und Methoden eingesetzt, sodass die gleiche Geschäftslogik je nach Anwendung immer wieder neu implementiert werden muss. Bei der Ab Initio-Software hingegen wird die Geschäftslogik nur einmal entwickelt und dann in die Batch- und Echtzeitinfrastrukturen von Ab Initio integriert:

Hohe Leistung für unterschiedliche Echtzeitausführungsmodelle

Anwendungsarchitekten stehen oft vor der Herausforderung, scheinbar widersprüchliche Leistungsanforderungen erfüllen zu müssen:

  • Batchanwendungen müssen Daten so effizient wie möglich verarbeiten. Die Ausführung eines Batchjobs kann viel Zeit in Anspruch nehmen, da sehr viele Transaktionen verarbeitet werden müssen und keine Ergebnisse vor Abschluss des gesamten Jobs verfügbar sind. Dennoch muss ein Batchjob während der Ausführung eine sehr große Anzahl von Datensätzen pro Sekunde verarbeiten.
  • Minibatchanwendungen sind Sammlungen von Batchjobs, die jeweils kleine Datenmengen verarbeiten. Allerdings können täglich tausende oder sogar zehntausende dieser kleinen Jobs ausgeführt werden. Die Antwortzeit eines Jobs wird minimiert, indem die durch den Job zu verarbeitende Datenmenge begrenzt wird. Auf diese Weise können dieselben Anwendungen sehr große Datenmengen in herkömmlichen Batchumgebungen äußerst effizient verarbeiten. (Die Verwaltung zehntausender Jobs pro Tag ist eine komplexe Aufgabe, die mit Conduct>It® von Ab Initio problemlos bewältigt werden kann.)
  • Asynchrone Messaging-Anwendungen stellen Verbindungen zu Message-Queues her und müssen Transaktionen ebenfalls so effizient wie möglich verarbeiten. Aber die nachfolgenden Systeme erwarten in der Regel innerhalb von wenigen bis einigen zehn Sekunden ihre Antworten. Wenn eine asynchrone Anwendung in der Lage ist, innerhalb von einer oder zwei Sekunden zu antworten, kann sie eine interaktive Nutzung unterstützen.
  • Von Request-/Response-(Anfrage-/Antwort)-Anwendungen bzw. synchronen Messaging-Anwendungen wird erwartet, dass sie eine Transaktion verarbeiten, sobald sie auftritt, und dass sie so schnell wie möglich antworten – in der Regel mit einer Latenzzeit von unter einer Sekunde. Wenn mehrere solcher Anwendungen gemeinsam eine Transaktion verarbeiten, müssen die einzelnen Anwendungen Antworten unter Umständen innerhalb von Zehntel- oder Hundertstelsekunden ausgeben. Die Ab Initio-Software ist direkt dafür ausgelegt, sinnvolle Arbeitseinheiten zuverlässig im Hundertstelsekundenbereich zu verarbeiten (im Unterschied zur extremen Auslegung mancher stark spezialisierten Systeme).

Mit Continuous>Flows bietet das Co>Operating System von Ab Initio eine Technologie, die von allen Kunden in allen beschriebenen Modi verwendet wird. Das ist deswegen möglich, weil das Co>Operating System von Anfang an so entworfen wurde, dass alle Anforderungen dieser unterschiedlichen Ansätze erfüllt werden.

Bei der Ab Initio-Software gibt es zwei Hauptunterschiede zwischen Batch- und Minibatch-Anwendungen auf der einen Seite und Echtzeitanwendungen auf der anderen Seite:

  • Beendigung: Batchanwendungen werden beendet, sobald sie die Verarbeitung aller Daten an ihren Eingängen abgeschlossen haben. Nach der Beendigung einer Batchanwendung sind keine Systemressourcen mehr mit ihr verbunden.

    Einmal gestartete Echtzeitanwendungen hingegen werden zeitlich unbeschränkt ausgeführt, um Transaktionen, die an ihren Eingängen ankommen, anzunehmen und zu verarbeiten. Wenn der Fluss neuer Transaktionen unterbrochen wird, wartet eine Echtzeitanwendung, bis neue Transaktionen eingehen.

  • Checkpoint-Verfahren und Wiederaufsetzen: Batchanwendungen erstellen an vorab festgelegten Punkten in einer Anwendung Checkpoints, sodass alle Daten, die durch einen dieser Punkte fließen, auf der Festplatte gespeichert werden (andernfalls wurde der Checkpoint nicht erfolgreich durchlaufen). Zum Wiederaufsetzen muss eine Anwendung lediglich am letzten erfolgreichen Checkpoint neu gestartet werden.

    Echtzeitanwendungen können Checkpoints zwischen Transaktionen erstellen, und zwar sehr oft, wie nach jeder Transaktion, oder weniger oft – z. B. auf der Grundlage von Kriterien wie verstrichener Zeit oder einer bestimmten Anzahl von Transaktionen. Eine neu gestartete Anwendung setzt die Arbeit automatisch bei der letzten Transaktion fort, für die erfolgreich ein Checkpoint erstellt wurde.

Schnittstellen zu einer Vielzahl von Echtzeitsystemen

Continuous>Flows von Ab Initio bietet Schnittstellen zu einer großen Anzahl von Echtzeitsystemen:

  • Queuing-Systeme von Drittanbietern: IBM MQ, JMS, RABBITMQ, KAFKA und MICROSOFT MQ. Ab Initio hat Komponenten für direkte Verbindungen mit all diesen Queuing-Systemen.
  • Web-Services: WEBSPHERE, WEBLOGIC, IIS und APACHE/TOMCAT
  • Ab Initio-Queues und RPC für Punkt-zu-Punkt-Verbindungen zwischen Ab Initio-Anwendungen mit kurzer Latenzzeit und großen Datenmengen
  • Legacy- bzw. interne Messaging-Software

Native Unterstützung für Web-Services und SOA

Ab Initio-Anwendungen können Web-Services problemlos in einer serviceorientierten Architektur (SOA) implementieren. Hierzu wird ein von Ab Initio bereitgestelltes Servlet eingesetzt, das auf einem vom Kunden gewählten Standard-Anwendungsserver installiert wird (WEBSPHERE, WEBLOGIC, IIS oder APACHE/TOMCAT). Das Servlet bietet einen Registrierungsmechanismus zur Zuordnung bestimmter Web-Service-Aufrufe zu entsprechenden Ab Initio-Anwendungen. Wenn ein Web-Service-Aufruf eingeht, kommuniziert das Servlet per TCP mit der Ab Initio-Anwendung (die Ab Initio-Anwendung wird in eigenständigen Prozessen außerhalb des Anwendungsservers ausgeführt) und übergibt die von der Ab Initio-Anwendung zurückgegebenen Ergebnisse an die Quelle des Aufrufs.

Das Co>Operating System bietet auch vollständige Unterstützung für das Parsen von WSDL-definierten Messages.

Schnittstellen zu Spezial- und Legacy-Message-Systemen

Kommerzielle Queuing-Produkte und Web-Services sind noch nicht sehr lange auf dem Markt und erreichen keine hohe Leistungsfähigkeit. Kunden mit großem Messaging-Volumen sowie Kunden, die schon vor dem Aufkommen kommerzieller Queuing-Produkte eine Messaging-Lösung benötigten, haben eigene interne Hochleistungslösungen entwickelt.

Continuous>Flows unterstützt durch spezielle Verarbeitungskomponenten („Universal Subscribe“ und „Universal Publish“) robuste Schnittstellen zu diesen Legacy-Lösungen. Diese Komponenten rufen benutzerdefinierte C++-Subroutinen auf, die Schnittstellen zum Legacy-Message-System bilden. Bei Ausfällen werden diese Komponenten auch für Rollback und Wiederherstellung eingesetzt.

Ab Initio-Software kann in Kombination mit Spezial-Message-Systemen eine extrem hohe Leistungsfähigkeit erreichen – in geschäftskritischen Anwendungen wurden dauerhafte Raten von über 500.000 Messages pro Sekunde gemessen.

Darüber hinaus werden die Komponenten Universal Subscribe und Universal Publish auf die gleiche Weise wie Continuous>Flows-Komponenten für Queuing-Produkte von Drittanbietern verwendet. So können Benutzer mit minimalen Änderungen an ihren Ab Initio-Anwendungen von ihrer internen Queuing-Lösung zu einem Queuing-Produkt eines Drittanbieters wechseln.

Robustheit bei Ausfällen

Die Checkpoint-Funktionalität des Co>Operating Systems sorgt für eine hohe Robustheit bei Anwendungsausfällen. Checkpoints ermöglichen es einer Anwendung, Änderungen per Commit an mehrere Datenbanken sowie Eingabe- und Ausgabesysteme (Queues) zu übergeben. Wenn eine Anwendung ausfällt, führt das Co>Operating System ein Rollback durch, um den Zustand zum Zeitpunkt des letzten erfolgreichen Checkpoints wiederherzustellen. Sobald das zugrunde liegende Problem gelöst wird (Datenbank kann nicht geladen werden, unzureichender Speicherplatz, Netzwerkausfall …), kann die Anwendung neu gestartet werden. Sie setzt die Arbeit dann automatisch nach der letzten erfolgreich verarbeiteten Transaktion fort.

Da die meisten Checkpoint-Verfahren mit hohem Rechenaufwand verbunden sind, versuchen Entwickler oft, diesen Aufwand zu minimieren. Dies führt jedoch häufig zu komplexen und instabilen Anwendungen. Das Co>Operating System wurde so entworfen, dass es eine extrem hohe Leistung bietet und äußerst robust ist. Zudem bietet das Co>Operating System mehrere Checkpoint-Alternativen, die Kompromisse zwischen Transaktionslatenz und Wiederherstellungszeit ermöglichen. In allen Fällen stellt das Co>Operating System sicher, dass jede Transaktion genau ein Mal auf alle Zielgeräte (Datenbanken, Dateien und Queues) geschrieben wird.

Das Co>Operating System bietet zwei grundlegende Checkpoint-Mechanismen. Der bekanntere dieser Mechanismen ist das XA-Standardprotokoll für Two-Phase-Commit. Hierfür hat das Co>Operating System einen Transaktionsmanager, der Commits über unterschiedliche Datenbanken und Queuing-Produkte koordiniert und Transaktionen sogar als Batch in einem einzigen Commit zusammenfassen kann, um den Durchsatz zu erhöhen.

Allerdings hat XA auch bestimmte Einschränkungen: Der Rechenaufwand ist hoch, die Verwaltung ist komplex, und es wird nicht von allen Eingabe- und Ausgabeelementen unterstützt. Daher verlassen sich die meisten Ab Initio-Benutzer auf den nativen Checkpoint-Mechanismus des Co>Operating Systems, der Two-Phase-Commit sehr ähnlich ist. Dieser Mechanismus funktioniert mit allen Eingabe- und Ausgabeelementen (Datenbanken, Dateien und Queues), mit denen die Ab Initio-Software verbunden werden kann; er kann in Umgebungen mit heterogenen und verteilten Servern eingesetzt werden; und er ist sehr leistungsfähig und äußerst robust. Ab Initio hat in seine Verbindungskomponenten sogar Mechanismen eingebaut, die Einschränkungen bestimmter Queuing-Produkte von Drittanbietern ausgleichen. Bei manchen Produkten kann beispielsweise ein Absturz des Queuing-Managers dazu führen, dass Transaktionen mehrmals übertragen werden.

Mit dem nativen Checkpoint-System des Co>Operating Systems können Entwickler die Checkpoint-Häufigkeit auf verschiedene Arten steuern, z. B. nach verstrichener Zeit oder einer bestimmten Anzahl von Transaktionen oder auch als Ergebnis von Ereignissen wie dem Auftreten eines bestimmten Zeichens im Message-Strom. Darüber hinaus können Entwickler festlegen, wie hoch die Transaktionskonsistenz zwischen mehreren Ausgabeelementen bei der Checkpoint-Erstellung sein soll. Mit den Standardeinstellungen wird eine sehr hohe Leistung erzielt; Transaktionen gehen nie verloren; und die Korrektheit der Anwendung wird stets aufrechterhalten.

Robuster Betrieb

Das Co>Operating System erfüllt die betrieblichen Anforderungen an geschäftskritische Echtzeitanwendungen auf vorbildliche Weise. Hierbei kommen u. A. folgende Mechanismen zum Einsatz:

  • Gleichzeitiges Ausführen mehrerer Instanzen einer Echtzeitanwendung für Lastausgleich und Ausfallsicherung
  • Beenden von Teilen eines Anwendungssystems, sodass aktualisierte Module initiiert werden können, ohne ein rund um die Uhr benötigtes System anzuhalten
  • Pooling von Datenbankverbindungen zur Beschränkung des Ressourceneinsatzes
  • Kombinieren mehrerer Komponenten zu einem einzigen Prozess, um die CPU- und Speicherbelastung zu verringern
  • Verwenden von „Mikrographen“, d. h. dynamisch ladbarer Graphlogik, um die Beanspruchung der Betriebssystemressourcen deutlich zu reduzieren

Zusammenfassung

Continuous>Flows ermöglicht dank grafischer Datenflussimplementierung eine erhebliche Produktivitätssteigerung bei der Echtzeitverarbeitung und bietet ein vielseitig einsetzbares Modell zum Verbinden mit Datenströmen sowie robuste Mechanismen zum zuverlässigen Erstellen von Checkpoints und Koordinieren von Transaktionen.

English
Français
Español
Sprache:
Deutsch
简体中文
日本語