Oswald Regular
OpenSans Regular
Das Co>Operating System
Breit und tief

Das Co>Operating System ist eine Umgebung zum Erstellen, Integrieren und Ausführen von Geschäftsanwendungen für Unternehmen. Es ist die Grundlage für alle Ab Initio-Technologien wie z. B. das Enterprise Meta>Environment, Continuous>Flows, Conduct>It, das Business Rules Environment usw. Diese Technologien bilden eine vollständige und nahtlose Umgebung zur Anwendungsentwicklung und -ausführung.

Der Kern des Co>Operating Systems ist eine „Datenfluss-Engine“. Diese Engine steuert eine große Bibliothek von Komponenten zur Bearbeitung der Daten, die durch eine Anwendung fließen. Anwendungen werden mit dem Graphical Development Environment (GDE) von Ab Initio grafisch entworfen, implementiert und verwaltet.

Das Grundprinzip des Co>Operating Systems besteht darin, dass Anwendungen ganz ähnlich wie auf einem Whiteboard (oder sogar auf einer Serviette) entworfen und entwickelt werden. Die Eingabe- und Ausgabequellen werden mit einfach erkennbaren Symbolen dargestellt, die dann mit Verarbeitungsfeldern und Linien kombiniert werden, um den gesamten Verarbeitungsfluss zu definieren. Sie erstellen eine Ab Initio-Anwendung, indem Sie die geeigneten Komponenten aus einer umfangreichen Bibliothek auswählen und miteinander verbinden.

Mit der Ab Initio-Software werden Entwurf und Ausführung von Anwendungen nahtlos integriert: Die Zeichnung ist die Anwendung. Und das Ergebnis kann eine Batch-, Fast-Echtzeit- oder Echtzeitanwendung oder sogar eine Kombination all dieser Anwendungstypen sein – zusammengeführt in einer einheitlichen und leistungsstarken Rechenumgebung.

Da der Ansatz von Ab Initio auf grafischen Datenflüssen basiert, eignet sich die Ab Initio-Software zum Erstellen fast aller heutiger Geschäftsanwendungen – von Datenverarbeitungssystemen und Systemen zur komplexen Ereignisverarbeitung und zur Integration verteilter Anwendungen bis hin zu Data Warehousing und Systemen zum Datenqualitätsmanagement. Aber die grafische Entwurfs- und Entwicklungsarbeitsweise deckt nur einen Teil der Herausforderungen ab, denn die erstellten Anwendungen müssen wichtige Betriebs- und Managementanforderungen erfüllen.

Mit herkömmlichen grafischen Programmierungstechniken entwickelte Anwendungen sind solchen Anforderungen in der Regel nicht gewachsen. Beim Co>Operating System sieht das ganz anders aus – es ist absolut praxistauglich! Nachfolgend werden einige Beispiele für Deployments und die ihnen zugrunde liegenden Anforderungen aufgeführt:

  • Für eine der größten Börsen der Welt wurden Millionen Zeilen COBOL-Code für geschäftskritische Operationen in Ab Initio-Anwendungen konvertiert. Die resultierende Lösung ist jetzt ein wichtiger Bestandteil der Trading-Verarbeitungspipeline. Sie ist mit dem Echtzeit-Trading-Bus verbunden und verarbeitet Transaktionen mit einer Rate von über 500.000 Nachrichten pro Sekunde.
  • Eines der weltweit größten Einzelhandelsunternehmen erhält in Echtzeit Warenkorbdaten von den Registrierkassen in Tausenden von Läden. Diese Daten werden zur Lagerverwaltung und Betrugserkennung verwendet.
  • Eine der größten Telekommunikationsgesellschaften der Welt verarbeitet detaillierte Anrufinformationen zu Zwecken der Gebührenerfassung und zur Netzwerk- und Datennutzungsüberwachung. Pro Tag werden Milliarden von Anrufdetail-Datensätze sowie Millionen Nutzungsabfragen verarbeitet.
  • Einer der weltweit größten Chiphersteller ruft Informationen zur Produktionsqualität in Echtzeit an der Fertigungslinie ab, um die Erträge zu steigern.
  • Eines der größten Kreditkartennetzwerke der Welt verwendet Ab Initio-Software als Daten-Backbone, um alle Transaktionen zu verarbeiten und im Batchmodus sowie in Echtzeit an Back-End-Systeme zu übergeben. Jährlich werden 1 Petabyte Transaktionsdaten in einem Datenaufbewahrungssystem von Ab Initio gesammelt, das Anfragen des Kundendienst-Callcenters in weniger als einer Sekunde beantwortet.
  • Eines der weltweit größten Internetunternehmen verarbeitet zu Abrechnungszwecken sowie für eine bessere Anzeigenplatzierung viele Milliarden Anzeigenaufrufe pro Tag.
  • Eine der größten Versicherungsgesellschaften der Welt setzt für einen Großteil der Schadensabwicklung Ab Initio-Software ein. Das Rückversicherungs- und Vertragsverarbeitungssystem dieses Unternehmens enthält mehrere zehntausend in Ab Initio-Software implementierte Regeln.
  • Einer der weltweit größten Paketzustelldienste erstellt Rechnungen und Umsatzvergütungen für seine Account-Teams in Ab Initio-Anwendungen.
  • Eine der größten Banken der Welt verdichtet Informationen über ihren gesamten Kundenbestand aus allen Geschäftsbereichen in einem riesigen Data Warehouse, das mit Ab Initio-Software erstellt wurde. Darüber hinaus nutzt die Bank Ab Initio-Software zum Anpassen und Verarbeiten des gesamten SWIFT-Transaktionsverkehrs zwischen ihren internationalen Niederlassungen.

Ihnen ist vielleicht aufgefallen, dass sich alle oben aufgeführten Beispiele auf Unternehmen beziehen, die jeweils zu den größten ihrer Branche gehören. Warum haben sich alle diese bedeutenden Unternehmen für Ab Initio entschieden? Weil Ab Initio-Software nicht nur intuitiv und benutzerfreundlich ist, sondern auch komplexeste Anwendungslogik sowie enorme Datenmengen unterstützt und dabei äußerst leistungsstark und außerordentlich robust ist. Diese Kombination ist einzigartig.

Oben wurden nur einige Beispiele für spezifische Deployments bei Kunden aufgeführt. Diese Deployments werden in der Regel für ein breites Spektrum von Aufgaben eingesetzt. Um die Anforderungen an all diese Anwendungen zu erfüllen, muss die Software sehr viele Leistungsmerkmale aufweisen, u. a. folgende:

  • Die Fähigkeit, große Mengen komplexer Logik grafisch darzustellen.
  • Nahezu allumfassende Konnektivität – zu einer Vielzahl von Datenbanken, Queuing-Systemen, flachen Dateien, ERP-Systemen, Standard-Message-Protokollen usw.
  • Native Unterstützung für komplexe Datenstrukturen, unabhängig von Art und Herkunft der Daten: hierarchisch (XML und Legacy), international, große Objekte, variable Länge, Bit-Packed-Daten usw.
  • Unterstützung für eine Vielzahl von Betriebssystemen (UNIX, LINUX, WINDOWS, Mainframes) sowie plattformübergreifende verteilte Verarbeitung.
  • Offene Architektur für eine schnelle Integration mit Legacy- und Drittanbieteranwendungen, -daten und -umgebungen.
  • Hohe Effizienz und hohe Skalierbarkeit sowie die Fähigkeit, eine cloudähnliche Rechenumgebung über Servernetzwerke zu ermöglichen.
  • Hochleistungsverarbeitung im Batch- und Echtzeitmodus (Web-Services und serviceorientierte Architekturen [SOA] sowie Streaming).
  • Einen hohen Grad an Wiederverwendbarkeit großer und kleiner Anwendungsteile, einschließlich Geschäftsregeln.
  • Hohe Unempfindlichkeit gegen Datenprobleme und Systemausfälle. Weitreichende Benutzerkontrolle über Fehlerbehebung.
  • Umfassende Managementfunktionen. Unterstützung des Softwareentwicklungslebenszyklus, einschließlich Versionskontrolle und Releasefreigabe. Ausführungsplanung, -überwachung und -warnmeldungen. Anwendungsanalyse und vieles mehr.

Diese Anforderungen können nur mit einer Architektur erfüllt werden, die von Anfang an entsprechend ausgelegt wurde. Sobald eine Architektur festgelegt wird, ist es nämlich nahezu unmöglich, ihr nachträglich grundlegende Funktionen hinzuzufügen. Das Co>Operating System wurde von Anfang an so entworfen, dass es alle diese Funktionen aufweist. Es ist eine robuste, bewährte Technologie, die für eine Vielzahl komplexer Datenverarbeitungsanwendungen verschiedenster Art eingesetzt wird.

Was ist eine Ab Initio-Anwendung?

Der Kern einer Ab Initio-Anwendung ist ein Datenflussgraph oder auch kurz „Graph“. Ein Graph besteht aus Komponenten, die durch „Datenflüsse“ miteinander verbunden sind.

Der folgende Graph ist eine einfache Anwendung, die jeden Datensatz aus einer flachen Datei mit Kundentransaktionen liest, die Daten dann neu formatiert (durch Anwenden von Regeln), anschließend sortiert und verdichtet. Die Ergebnisse dieser Verarbeitung werden dann in eine Datenbanktabelle (z. B. ORACLE) geschrieben.

Durch die Verwendung hoch konfigurierbarer Komponenten umfasst das Co>Operating System von Ab Initio alle grundlegenden Bausteine für die Verarbeitung von Geschäftsdaten. Hierzu zählen unter anderem:

  • Datentransformationen
  • Auswahl/Filterung
  • Deduplizierung
  • Zusammenführen/zusammenfügen
  • Normalisieren/denormalisieren
  • Komprimieren/dekomprimieren
  • Aggregieren/kumulativ verarbeiten
  • Sortieren
  • Datengenerierung und -validierung
  • ...und mehr

Darüber hinaus bietet das Co>Operating System eine große Bibliothek integrierter Komponenten für den Umgang mit nahezu jeder Art von Datenquelle oder -ziel. Diese Bibliothek umfasst Komponenten für folgende Aufgaben:

  • Verbinden mit flachen Dateien jeder Art in UNIX, WINDOWS und Mainframes
  • Verbinden mit allen gebräuchlichen (und vielen weniger gebräuchlichen) Datenbanken (ORACLE, DB2, TERADATA, SQL SERVER, NETEZZA, GREENPLUM, Mainframe DB2, IMS, IDMS, ADABAS ...)
  • Verbinden mit allen Standardinfrastrukturen für Message-Queuing (IBM MQ, JMS, MICROSOFT MQ)
  • Verbinden mit Web-Service-Infrastrukturen (WEBSPHERE, WEBLOGIC, IIS, APACHE/TOMCAT ...)
  • Verbinden mit vielen Produkten von Drittanbietern (SAP, SIEBEL, SAS, PEOPLESOFT, SALESFORCE.COM ...)
  • Parsen und Manipulieren von hierarchischen Datenstrukturen (XML, ASN.1, COBOL ...)
  • Parsen, Manipulieren und Generieren domänenspezifischer Datenformate (SWIFT, FIX, EDIFACT ...)
  • Inhaltsbasiertes Message-Routing
  • Metadatenkonnektivität zu einer Vielzahl von Datendefinitions- und Business-Intelligence-Produkten (ERWIN, ERSTUDIO, MICROSTRATEGY, BUSINESS OBJECTS, COGNOS ...)

Kleine Anwendungen können beispielsweise nur 3 bis 5 Komponenten enthalten, große Anwendungen hingegen hundert Komponenten und sehr große Anwendungen sogar viele tausend Komponenten. Anwendungen können auch aus vielen Graphen bestehen, die jeweils viele Komponenten enthalten können.

Unabhängig von ihrer Größe nutzen alle Ab Initio-Anwendungen wiederverwendbare Regeln und Komponenten und können daher schnell an sich ändernde Geschäftsanforderungen angepasst werden.

Die Geschäftslogik wird rein grafisch spezifiziert.

Unterhalb der Komponentenebene kann das Co>Operating System nahezu jegliche Art von benutzerdefinierten Regeln und Logik auf jeden Datentyp anwenden. Und dabei werden sämtliche Regeln grafisch festgelegt. Bei anderen Technologien ist dies höchstens für einfache Regeln möglich. Sobald die Regeln etwas komplexer werden, kommt der Benutzer nicht weiter und muss schließlich stattdessen herkömmliche Programmiermethoden (JAVA, C++, Skripting, Stored Procedures, PERL ...) verwenden.

Mit dem Co>Operating System sieht das ganz anders aus. Sobald Benutzer das Co>Operating System haben, stellen sie schnell fest, dass es einfacher ist, komplexe Logik innerhalb des Co>Operating Systems festzulegen als außerhalb. Dies hat enorme Auswirkungen auf die Produktivität, Benutzerfreundlichkeit und Transparenz, da es wesentlich einfacher und schneller ist, die Regeln grafisch zu definieren. Zudem sind sie für Geschäftsanwender leichter zu verstehen.

Im Co>Operating System definieren Sie Regeln mit der DML (Data Manipulation Language) von Ab Initio und verwenden sie in „Transformationskomponenten“. Diese Komponenten sind die grundlegenden Bausteine für die Datenverarbeitung. Es gibt Transformationskomponenten für das Zuweisen einer Art von Datensatzstruktur zu einer anderen, für das Aggregieren und Filtern von Daten, für das Normalisieren und Denormalisieren von Strukturen, für das Zusammenführen mehrerer Datensatzströme usw. Jede dieser Komponenten kann in DML festgelegte Regeln auf die Datensätze anwenden, während diese verarbeitet werden.

Der folgende Screenshot zeigt eine einfache Regel, mit der die Ausgabedaten einer Zuweisungskomponente berechnet werden. Links werden die in die Komponente eingehenden Felder angezeigt, rechts die aus der Komponente ausgehenden Felder und in der Mitte die Regeln.

Mit dem unten gezeigten „Ausdruckseditor“ können einzelne Regeln erstellt werden. Ausdrücke können beliebig groß und komplex sein. Die DML bietet eine große Bibliothek integrierter Operatoren und Funktionen.

Die Ab Initio-Software unterstützt auch alternative Benutzeroberflächen für die Definition von Geschäftsregeln. Diese Benutzeroberflächen richten sich an Benutzer, die technisch weniger versiert sind, wie z. B. Geschäftsanalysten und Experten für bestimmte Fachgebiete. Diese Benutzer verwenden eher geschäftliche als technische Begriffe und organisieren Regeln wie in einer gängigen Kalkulationstabelle:

Klicken Sie hier, um mehr über das Business Rules Environment (Geschäftsregelumgebung, BRE) zu erfahren.

Das Co>Operating System verarbeitet jeden Datentyp nativ

Mit dem Co>Operating System ist es nicht nötig, Daten in eines von wenigen integrierten Formaten zu übersetzen. Stattdessen verarbeitet das Co>Operating System die Daten in ihrem nativen Format, und zwar auf allen unterstützten Betriebssystemen auf gleiche Weise. Daher können das Co>Operating System und alle Ab Initio-Komponenten Daten nativ verarbeiten: Mainframedaten auf UNIX- und WINDOWS-Servern, XML auf Mainframes, komplexe hierarchische und Bit-Packed-Strukturen überall, internationale Daten mit automatischer Transcodierung usw. Mit denselben Daten und derselben Anwendung gibt das Co>Operating System stets dieselben Ergebnisse aus, unabhängig davon, wo die Anwendung läuft.

Anwendungen können Daten in einer heterogenen Gruppe von Systemen lesen und schreiben, wobei die Daten an verschiedenen Punkten in der Anwendung sehr unterschiedliche Formate aufweisen können. Das folgende Beispiel zeigt eine Anwendung, die Mainframedaten aus einer flachen Datei und XML-Daten aus einer MQ-Queue liest, die Daten mit verschiedenen intermediären Formaten verarbeitet und die Ergebnisse unter Verwendung eines internationalen Codesatzes in eine flache Datei ausgibt.

Das Co>Operating System kann Datenformate aus jedem Speicherort abrufen, sei es aus Datenbankkatalogen, Schemadefinitionsprodukten, COBOL-Copybooks, XML-DTDs oder -XSDs, WSDL, Kalkulationstabellen oder internen Datenformatsystemen.

Das Datensatzformat des intermediären Flusses „ASCII hierarchisch“ im obigen Beispiel könnte wie folgt aussehen:

Schließlich können das Co>Operating System und seine Komponenten bei Bedarf auch Formate automatisch übersetzen. Wenn beispielsweise EBCDIC-Daten und gepackte Dezimalzahlen an eine Komponente übergeben werden, die in eine ORACLE-Datenbank schreibt, übersetzt die Komponente die Daten automatisch in ASCII und Dezimalzahlen, wenn die Spalten in der Datenbank diese Formate aufweisen.

Leistung und Skalierbarkeit

Das Co>Operating System wurde von Grund auf für ein Maximum an Leistung und Skalierbarkeit konzipiert. Jeder Aspekt des Co>Operating Systems wurde dahin gehend optimiert, dass die maximale Leistung mit der verfügbaren Hardware erbracht wird. Und da das Co>Operating System naturgemäß die Verarbeitung auf Serverfarmen verteilt, wird keine Cloudtechnologie benötigt.

Das Co>Operating System ist in der Regel mindestens 4- bis 5-mal schneller als die nächstschnelle Technologie – einschließlich manuell in JAVA und C++ codierter Programme: Nur die wenigsten Programmierer können Programme schreiben, die so schnell laufen wie ein entsprechendes Ab Initio-Programm! Selbst wenn ein Unternehmen über einen entsprechend qualifizierten JAVA- oder C++-Programmierer verfügt, wäre dieser wochenlang damit beschäftigt, etwas zu codieren, was mit der Ab Initio-Software in wenigen Tagen implementiert werden könnte. Zudem arbeiten derart talentierte Programmierer in der Regel nicht lange nur als Codierer, sondern sie werden mit anderen Aufgaben betraut – beispielsweise mit Entwurf, Architektur und sogar Projektmanagement.

Wie erreicht Ab Initio Skalierbarkeit und Leistung? Was ist das „Geheimrezept“ von Ab Initio? Dieses Rezept hat viele Zutaten, aber besonders hervorzuheben sind die Architektur und eine an Besessenheit grenzende Detailgenauigkeit. Die Architektur des Co>Operating Systems wurde von Grund auf mit Blick auf Skalierbarkeit konzipiert.

Für die Architektur des Co>Operating Systems gilt das „Shared-Nothing“-Prinzip (nichts gemeinsam verwenden). Da das Co>Operating System nicht verlangt, dass die CPUs überhaupt etwas gemeinsam verwenden, können sie völlig unabhängig voneinander arbeiten. Daher kann eine Anwendung über beliebig viele CPUs auf beliebig vielen Servern ausgeführt werden. Mit dem Co>Operating System kann die Arbeitslast gleichmäßig auf viele CPUs verteilt werden, sodass die meisten Anwendungen linear skalierbar sind. Dies bedeutet, dass die Leistung durch eine Verdoppelung der CPU-Anzahl verdoppelt und durch eine Verzehnfachung der CPU-Anzahl verzehnfacht werden kann. Das Co>Operating System maximiert durch die Kombination von Datenparallelität mit Pipelineparallelität die Möglichkeiten, Teile einer Anwendung gleichzeitig auszuführen.

Im folgenden einfachen Beispiel wird gezeigt, wie eine Anwendung Daten so partitioniert, dass die Score-Komponente parallel auf vielen CPUs (und Servern) ausgeführt werden kann. Die Partition-by-Round-Robin-Komponente unterteilt die Kundendaten in gleich große Datenströme, vergleichbar mit dem Kartenausteilen zu Beginn eines Kartenspiels. Das Co>Operating System führt daraufhin mehrere Instanzen der Score-Komponente aus, die jeweils einen Datenstrom verarbeiten. Während die einzelnen Instanzen des Score-Programms einzelne Datensätze ausgeben, fügt die Interleave-Komponente die Ströme wieder zusammen, bevor sie die Ergebnisse in die Ausgabedatei schreibt. So einfach ist das.

Architekturen, für die das „Shared-Nothing“-Prinzip gilt, funktionieren wunderbar, solange keine Engpässe auftreten. Aber mit einem einzigen Engpass bricht das Ganze zusammen. Daher ist die Detailgenauigkeit so wichtig. Jeder Teil des Systems, der einen seriellen Engpass verursachen könnte, muss sorgfältig entworfen und so implementiert werden, dass er keine Probleme verursacht. Alle Algorithmen in allen Komponenten müssen in vielen verschiedenen Szenarios optimal arbeiten. Für jegliche Kommunikation und den gesamten Datentransport zwischen Partitionen und Komponenten müssen die effizientesten Kanäle verwendet werden. Das System skaliert nur, wenn alle diese Details und viele weitere Aspekte berücksichtigt werden.

Ein weiteres entscheidendes Detail besteht in der Ausführung von Geschäftsregeln. Wenn das System richtig entworfen wurde, sollte ein Großteil der CPU-Zeit hierfür aufgewendet werden. Die Geschäftsregeln werden von der Transformations-Engine des Co>Operating Systems ausgeführt. Da diese Engine als „Just-in-Time-Compiler“ arbeitet, kompiliert das Co>Operating System die Geschäftsregeln erst im letzten Moment, d. h. erst dann, wenn alle für ihre Ausführung relevanten Informationen verfügbar sind. Dies ermöglicht eine sehr hohe Flexibilität, und der Compiler ist dafür optimiert, herkömmliche Geschäftslogik mit maximaler Leistung auszuführen. Daher können Programmierer, die mit herkömmlichen Technologien arbeiten, kaum mit dem Co>Operating System konkurrieren.

Das Verarbeitungsmodell des Co>Operating Systems

Das Co>Operating System ist ein verteiltes Peer-to-Peer-Verarbeitungssystem. Es muss auf allen Servern installiert werden, die an der Ausführung einer Anwendung beteiligt sein sollen. Auf jedem dieser Server kann ein anderes Betriebssystem ausgeführt werden (UNIX, LINUX, ZLINUX, WINDOWS oder Z/OS).

In den folgenden Diagrammen wird beschrieben, wie das Co>Operating System einen verteilten Satz von Prozessen in einem Servernetzwerk verwaltet:

Funktionsweise des Co>Operating Systems
1.
Das Co>Operating System wird auf dem „Master“-Server gestartet,
der Anwendungsdefinitionen, Datenformate, Logikregeln, Parameter usw. einliest.
2.
Das Co>Operating System startet „Agenten“ auf anderen Servern.
3.
Der Master-Prozess informiert jeden Agenten über Komponenten, die auf diesem
Server ausgeführt werden sollen. Zudem übermittelt er alle zur Ausführung der
Komponenten benötigten Informationen.
4.
Agenten starten Komponenten und teilen ihnen die Regeln, Datensatzformate, Parameter usw. mit.
5.
Komponenten verbinden die Datenflüsse und beginnen mit der Datenverarbeitung.
Agenten überwachen die Verarbeitung.

1. Das Co>Operating System wird auf dem „Master“-Server gestartet, der Anwendungsdefinitionen, Datenformate, Logikregeln, Parameter usw. einliest.

2. Das Co>Operating System startet „Agenten“ auf anderen Servern.

3. Der Master-Prozess informiert jeden Agenten über Komponenten, die auf diesem Server ausgeführt werden sollen. Zudem übermittelt er alle zur Ausführung der Komponenten benötigten Informationen.

4. Agenten starten Komponenten und teilen ihnen die Regeln, Datensatzformate, Parameter usw. mit.

5. Komponenten verbinden die Datenflüsse und beginnen mit der Datenverarbeitung. Agenten überwachen die Verarbeitung.

Wie Sie in diesen Diagrammen sehen, kann eine einzelne Ab Initio-Anwendung auf einem einzelnen Server oder in einem Servernetzwerk ausgeführt werden. Die Definition der Anwendung, d. h. das vom Entwickler festgelegte grafische Diagramm, ist in beiden Fällen identisch. Um eine Anwendung auf einer anderen Gruppe von Servern auszuführen, müssen lediglich andere Ausführungsorte für die entsprechenden Komponenten festgelegt werden. Die Anwendung selbst muss nicht geändert werden. Einer Anwendung kann daher problemlos ein neuer Host zugewiesen werden. So ist beispielsweise ein Wechsel von Mainframes zu einem UNIX-Server oder von einem einzelnen Server zu einer Serverfarm jederzeit ohne Änderungen an der Anwendung möglich.

Das Co>Operating System läuft problemlos unter UNIX, WINDOWS, LINUX, ZLINUX und Z/OS. Darüber hinaus kann eine Anwendung auf jeder beliebigen Kombination dieser Plattformen ausgeführt werden. Jede Komponente einer Ab Initio-Anwendung kann auf jeder Plattform ausgeführt werden, auf der das Co>Operating System installiert ist (mit Ausnahme weniger plattformspezifischer Komponenten wie VSAM-Zugriff auf Mainframes). Das Co>Operating System übernimmt die mit dem Verschieben von Daten zwischen den Computern verbundene Komplexität und stellt somit eine nahtlose Middleware und Verarbeitungsfähigkeit bereit. Außerdem kann die Zuteilung von Komponenten an Zielcomputer vor jeder Ausführung einer Anwendung geändert werden.

Jede Komponente oder Komponentengruppe kann einer anderen Computerressource zugewiesen werden:

Batch-, Echtzeit- und Web-Service-Systeme – Das Co>Operating System kann alles

Die Anforderungen beim Erstellen und Betreiben von Batch- und Echtzeitanwendungen sind sehr unterschiedlich. Auch die hierfür eingesetzten Technologien hatten sich bislang stark unterschieden. Mit dem Co>Operating System sieht das ganz anders aus. Das Co>Operating System hat eine einheitliche Architektur, die sich gleich gut für Batch-, Echtzeit- und Web-Service (SOA)-Systeme eignet. Mit dem Co>Operating System und Continuous>Flows ist es nicht erforderlich, mehrere Technologien und verschiedene Entwicklungsteams für jedes System sowie möglicherweise mehrere Implementierungen derselben Geschäftslogik einzusetzen. Stattdessen können Sie mit einer einzigen Technologie, einem einzigen Entwicklungsteam und einer einzigen, in verschiedenen Systemen verwendbaren Codierung der Geschäftslogik arbeiten.

Ob eine Anwendung als Batch- oder Echtzeitsystem ausgeführt wird, hängt beim Co>Operating System davon ab, was die Anwendung liest und schreibt. Hier wird ein und dieselbe Anwendung in drei Varianten gezeigt – erst als Batchsystem (mit flachen Dateien für die Eingabe und Ausgabe verbunden), dann als Echtzeit-Queuing-System (MQ für die Eingabe und JMS für die Ausgabe) und schließlich als Web-Service, der Serviceanfragen von einem externen System erhält und Ergebnisse an dasselbe System zurückgibt:

Eine Anwendung, viele Ausprägungen

1. BATCH

2. Queuing.

3. Web-Services:

Klicken Sie hier, um mehr über Continuous>Flows zu erfahren.

Integration mit Legacy-Codes

Obwohl die Ab Initio-Software es möglich macht, durchgehende Anwendungen komplett mit der GDE zu erstellen und sie vollständig innerhalb des Co>Operating Systems auszuführen, kommt es oft vor, dass Benutzer bestehende Anwendungen oder Produkte von Drittanbietern haben, die einwandfrei funktionieren und deren erneute Implementierung nicht lohnenswert erscheint. Mit der Ab Initio-Software ist es einfach, diese Anwendungen wieder zu verwenden, egal, ob sie in C, C++, COBOL, JAVA, als Shell-Skripte oder auf andere Weise codiert wurden. Mit dem Co>Operating System können diese Anwendungen sogar in Umgebungen integriert werden, für die sie ursprünglich nicht gedacht waren.

Legacy-Codes werden in Ab Initio-Anwendungen integriert, indem sie in Komponenten umgewandelt werden, die sich wie alle anderen Ab Initio-Komponenten verhalten. Bei den meisten Legacy-Codes ist dies ganz einfach: man braucht nur eine Spezifikation der Eingaben und Ausgaben des Programms mit den Kommandozeilenparametern. Im folgenden Beispiel wird gezeigt, wie ein COBOL-Programm, das flache Dateien lesen und schreiben kann, mit einer Ab Initio-Anwendung integriert wird. Zunächst wird der COBOL-Code zusammen mit den Copybooks und dem JCL-Code in eine Ab Initio-Komponente umgewandelt. Danach wird diese Komponente in einer Ab Initio-Anwendung platziert, die auf UNIX-Servern und einem Mainframe ausgeführt wird, und anschließend wird die Anwendung mit verschiedenen Datenquellen und -zielen verbunden (SAS und einer Datenbank). Abschließend wird die Arbeitslast partitioniert, sodass mehrere Instanzen des COBOL-Codes parallel laufen können.

Integration von Legacy-Code
Benutzer sammeln COBOL-spezifische Daten
wie die folgenden ein und fügen sie hinzu:
Diese Komponente kann mit allem
verbunden werden, womit die
Ab Initio-Software kommunizieren kann.
Derselbe COBOL-Code ist jetzt Teil eines Systems, das UNIX und MAINFRAME umfasst
und mit SAS und RDBMS verbunden ist.
UNIX
MAINFRAME

Sehr hohe Unempfindlichkeit gegen ungültige Daten

Eine der schwierigsten Aufgaben bei der Erstellung und Verwaltung realer Systeme ist der Umgang mit unerwarteten oder ungültigen Daten. Wenn solche Daten an Anwendungen übergeben werden – was in der Praxis häufig vorkommt –, reagieren die meisten Anwendungen auf unerwünschte Weise. Wenn sie nur abstürzen, hat man noch einmal Glück gehabt. In anderen Fällen jedoch verarbeiten die Anwendungen die ungültigen Daten fehlerhaft, was unter Umständen erst auffällt, nachdem die ungültigen Ergebnisse an nachfolgende Systeme übergeben wurden und dort zu Folgeschäden geführt haben. Das daraus resultierende Chaos ist nur mit großem Zeitaufwand wieder zu beseitigen, was wiederum mit erheblichen Produktivitätseinbußen verbunden ist.

Das Co>Operating System ist inhärent widerstandsfähig gegen ungültige Daten und prüft kontinuierlich, ob die Daten verschiedene benutzerdefinierte und systemspezifische Kriterien einhalten. Wenn die Daten diesen Kriterien nicht entsprechen, darf die Verarbeitung erst nach einem korrigierenden Eingriff fortgesetzt werden. Entwickler können entsprechende automatisierte Eingriffs- und Berichtsfunktionen problemlos in die Anwendung integrieren. Die Eingriffe können so ausgelegt sein, dass fehlerhafte Daten korrigiert und wieder an das System übergeben werden, oder sie können darin bestehen, alle betroffenen Datenobjekte auszusondern, um sie zu einem späteren Zeitpunkt einheitlich verarbeiten zu können.

Im folgenden Beispiel wird gezeigt, wie ein Entwickler mithilfe der Ab Initio-Software eine Anwendung erstellt, die folgende Schritte ausführt: (1) Erfassen der ungültigen Daten, (2) Verarbeiten der ungültigen Daten mit einem Bereinigungsregelsatz, (3) Zurückführen der bereinigten Daten in den ursprünglichen Prozess, (4) Absondern von Daten, die nicht bereinigt werden können, (5) Generieren eines Berichts über die ungültigen Daten und (6) Versenden dieses Berichts über eine MQ-Queue.

Alle Ab Initio-Komponenten, die Daten auf relevante Weise verarbeiten, verfügen über optionale Reject (Abweisungs)-, Error (Fehler)- und Log (Protokollierungs)-Ports. Der Reject-Port erhält alle ungültigen Daten; der Error-Port erhält einen entsprechenden Datensatz, in dem das jeweilige Problem beschrieben wird; und der Log-Port erhält Debugginginformationen. So können extrem robuste Verarbeitungspipelines erstellt werden.

Sehr hohe Widerstandsfähigkeit gegen Systemausfälle

Server und Netzwerke können ausfallen, und das Laden von Datenbanken kann fehlschlagen. Je mehr Server an einer Anwendung beteiligt sind, desto größer ist die Wahrscheinlichkeit eines Systemausfalls. Es ist schwierig, Anwendungen zu erstellen, die die Arbeit nach solchen Ausfällen zuverlässig wiederaufnehmen. Viele Entwickler sind zwar davon überzeugt, dass sie es können, aber Sie als Benutzer werden erst erfahren, ob die Architektur robust ist, nachdem Sie mit verschiedenen Arten von Ausfällen konfrontiert wurden. Und dieser Erfahrungsprozess kann mit sehr viel Ärger verbunden sein.

Das Co>Operating System hingegen wurde von Anfang an dafür ausgelegt, dass die Arbeit nach Ausfällen aller Art zuverlässig wiederaufgenommen werden kann. Wenn die Umgebung so konfiguriert ist, dass wichtige Daten nicht verloren gehen, kann die Checkpoint/Neustart-Funktionalität des Co>Operating Systems eine Anwendung an dem Punkt erneut starten, an dem sie vor dem Ausfall beendet wurde. Dies ist auch dann möglich, wenn die Anwendung sich über mehrere Netzwerke, Server und Datenbanken erstreckt, und zwar unabhängig davon, ob sie im Batch- oder Echtzeitmodus ausgeführt wird. Das Co>Operating System verwendet einen Two-Phase-Commit-ähnlichen Mechanismus, der wesentlich leistungsstärker als das auf Industriestandard basierende XA-Protokoll ist. Für Umgebungen, die das XA-Protokoll erfordern, wird auch das vom Co>Operating System unterstützt – sogar für mehrere Datenbanken und Queuing-Technologien unterschiedlicher Hersteller.

Das Co>Operating System erhöht die Produktivität durch hohe Wiederverwendung

Aufgrund der Art der Probleme, die Ab Initio-Anwendungen lösen, können sie sehr groß und komplex werden. Allerdings enthalten die meisten Systeme viele Teile, die einander stark ähneln oder die viele Variationen eines einzigen Sachverhalts abbilden. Bei herkömmlichen Programmierungstechniken erstellen Entwickler Kopien dieser Teile und nehmen dann geringfügige Änderungen an jeder Kopie vor. Das Ergebnis ist ein Verwaltungs- und Produktivitätsalbtraum.

Ab Initio hingegen bietet eine Reihe von Mechanismen, mit denen die Wiederverwendung dieser Anwendungsteile enorm erhöht wird. Anwendungsteile jeder Art können im Enterprise Meta>Environment (EME) von Ab Initio, einem zentralisierten Repository, gespeichert und innerhalb einer Anwendung sowie anwendungsübergreifend wiederverwendet werden. Nachfolgend werden einige Beispiele für Objekte aufgeführt, die zentral gespeichert, verwaltet und wiederverwendet werden können:

  • Datensatzformate
  • Geschäfts- und Logikregeln
  • Anwendungsabschnitte (Anwendungen werden als „Graphen“ bezeichnet und Anwendungsabschnitte als „Subgraphen“)
  • Orchestrierungen von Anwendungen (in Conduct>It von Ab Initio „Pläne“ genannt)

Die Wiederverwendungsfähigkeit der Ab Initio-Software ist äußerst leistungsstark. Wiederverwendete Anwendungsteile können mit der zentralisierten Version, aus der sie stammen, verknüpft werden und Änderungen an dieser Version verfolgen. Darüber hinaus können diese Teile lokal angewendete Anpassungen unterstützen und weiterhin die zentralisierte Version verfolgen.

Im folgenden Beispiel wird eines dieser wiederverwendbaren Anwendungsmodule gezeigt: der Subgraph. Ein Subgraph kann die Komponenten eines Unterabschnitts einer Anwendung (d. h. eines Graphen) enthalten. Die Größe und Komplexität von Subgraphen sind unbegrenzt. Zudem können Subgraphen verschachtelt sein. Subgraphen verhalten sich genauso wie normale Komponenten. Sie können auch in einer Bibliothek gespeichert werden, sodass sie in vielen Anwendungen wiederverwendet werden können.

Dieser Subgraph entspricht dem Fehlerbehandlungsteil der weiter oben beschriebenen Anwendung:

Beachten Sie, dass die Komponenten in diesem Subgraph nicht explizit mit einer Eingabe- oder Ausgabekomponente verbunden sind, sondern mit den Eingabe- und Ausgabeports des Subgraphen „Standardmäßiger Fehlerbehandlungsprozess“.

Nachstehend wird die gleiche Anwendung wie oben gezeigt, diesmal allerdings mit dem neuen, wiederverwendbaren Fehlerbehandlungssubgraphen (Subgraphen werden in der GDE durch eine zusätzliche umlaufende Rahmenlinie gekennzeichnet):

Zusammenfassung

Das Co>Operating System ist die Basissoftware für die gesamte Ab Initio-Architektur. Alle wichtigen Architekturkonzepte von Ab Initio sind im Co>Operating System implementiert. Da alle Technologien von Ab Initio das Co>Operating System auf die eine oder andere Weise einschließen, schließen sie auch diese Konzepte auf einheitliche und nahtlose Art ein.

Diese Architektur hat folgende Vorteile:

  • Ganze Anwendungssysteme können ohne herkömmliche Codierung grafisch erstellt werden.
  • Mitarbeiter in den Bereichen technische Entwicklung und Wartung sind dank der grafischen Methode wesentlich produktiver als es mit herkömmlicher Codierung möglich ist.
  • Technische Mitarbeiter können viel besser auf sich ändernde Geschäftsanforderungen reagieren.
  • Da die Anwendungen wesentlich transparenter sind, können Geschäftsanwender und Analysten sie besser verstehen.
  • Sie sind unbegrenzt skalierbar und plattformübergreifend portierbar, sie können mit jeder Art von komplexen Daten arbeiten, sie können äußerst komplexe Geschäftsregeln implementieren, sie können problematischen Daten und Systemausfällen standhalten usw.
  • Anwendungen können die Geschäftslogik in Batch-, Echtzeit- und Web-Service-Anwendungen wiederverwenden.

All das und vieles mehr ist möglich, weil das Co>Operating System von Anfang an mit einer einheitlichen Architektur entworfen wurde, die diese Ergebnisse ermöglicht.

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