AWS Der Mainframe Modernization Service (Managed Runtime Environment Experience) steht Neukunden nicht mehr zur Verfügung. Funktionen, die dem AWS Mainframe Modernization Service (Managed Runtime Environment-Erfahrung) ähneln, finden Sie unter AWS Mainframe Modernization Service (Self-Managed Experience). Bestandskunden können den Service weiterhin wie gewohnt nutzen. Weitere Informationen finden Sie unter Änderung der Verfügbarkeit von AWS Mainframe Modernization.
Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
AWS Transformation für Mainframe-Runtime-Architektur auf hohem Niveau
Als Teil der AWS Transform for Mainframe-Lösung zur Modernisierung älterer Programme auf Java bietet AWS Transform for Mainframe Runtime einen einheitlichen, REST-basierten Einstiegspunkt für modernisierte Anwendungen und ein Framework für die Ausführung solcher Anwendungen. Dabei werden Bibliotheken verwendet, die Legacy-Konstrukte bereitstellen und die Organisation des Programmcodes standardisieren.
Solche modernisierten Anwendungen sind das Ergebnis des AWS Transform for Mainframe Automated Refactor-Prozesses zur Modernisierung von Mainframe- und Midrange-Programmen (im folgenden Dokument als „Legacy“ bezeichnet) auf eine webbasierte Architektur.
Die Ziele von AWS Transform for Mainframe Runtime sind die Reproduktion des Verhaltens älterer Programme (Isofunktionalität), die Leistung (in Bezug auf die Ausführungszeit und den Ressourcenverbrauch) und die einfache Wartung modernisierter Programme durch Java-Entwickler, obwohl vertraute Umgebungen und Redewendungen wie Tomcat, Spring, Getters/Setter, Fluent verwendet werden APIs.
Topics
AWS Transformation für Mainframe-Runtime-Komponenten
Die Runtime-Umgebung AWS Transform for Mainframe besteht aus zwei Arten von Komponenten:
-
Eine Reihe von Java-Bibliotheken (JAR-Dateien), die häufig als „gemeinsam genutzter Ordner“ bezeichnet werden und ältere Konstrukte und Anweisungen bereitstellen.
-
Eine Reihe von Webanwendungen (WAR-Dateien), die auf Spring basierende Webanwendungen enthalten und einen gemeinsamen Satz von Frameworks und Diensten für modernisierte Programme bereitstellen.
In den folgenden Abschnitten wird die Rolle dieser beiden Komponenten detailliert beschrieben.
AWS Transformation für Mainframe-Bibliotheken
Die AWS Transform for Mainframe-Bibliotheken bestehen aus einer Reihe von JAR-Dateien, die in einem shared/ Unterordner gespeichert werden, der dem Standard-Tomcat-Klassenpfad hinzugefügt wird, um sie allen modernisierten Java-Programmen zur Verfügung zu stellen. Ihr Ziel ist es, Funktionen bereitzustellen, die in der Java-Programmierumgebung weder nativ noch einfach verfügbar sind, aber für ältere Entwicklungsumgebungen typisch sind. Diese Funktionen werden auf eine Weise bereitgestellt, die Java-Entwicklern so vertraut wie möglich ist (Getter/Setter, klassenbasiert, fließend). APIs Ein wichtiges Beispiel ist die Data Simplifier-Bibliothek, die ältere Speicherlayout- und Manipulationskonstrukte (wie sie in COBOL- oder RPG-Sprachen vorkommen) für Java-Programme bereitstellt. PL1 Diese JAR-Dateien sind eine Kernabhängigkeit des modernisierten Java-Codes, der aus älteren Programmen generiert wurde. Weitere Informationen zum Data Simplifier finden Sie unter. Was sind Datenvereinfacher in AWS Transform for Mainframe
Webanwendung
Webanwendungsarchive (WARs) sind eine Standardmethode für die Bereitstellung von Code und Anwendungen auf dem Tomcat-Anwendungsserver. Diejenigen, die als Teil der AWS Transform for Mainframe-Laufzeit bereitgestellt werden, zielen darauf ab, eine Reihe von Ausführungs-Frameworks bereitzustellen, die ältere Umgebungen und Transaktionsmonitore (JCL-Batches, CICS, IMS...) und die zugehörigen erforderlichen Dienste reproduzieren.
Das wichtigste ist gapwalk-application (oft abgekürzt als „Gapwalk“), das einen einheitlichen Satz von REST-basierten Einstiegspunkten zum Auslösen und Steuern der Ausführung von Transaktionen, Programmen und Batches bietet. Weitere Informationen finden Sie unter AWS Transformation für Mainframe-Runtime APIs.
Diese Webanwendung weist Java-Ausführungsthreads und Ressourcen zu, um modernisierte Programme in dem Kontext auszuführen, für den sie entworfen wurden. Beispiele für solche reproduzierten Umgebungen werden im folgenden Abschnitt detailliert beschrieben.
Andere Webanwendungen fügen der Ausführungsumgebung (genauer gesagt der unten beschriebenen „Programmregistrierung“) Programme hinzu, die diejenigen emulieren, die für die älteren Programme verfügbar sind und von diesen aufgerufen werden können. Zwei wichtige Kategorien davon sind:
-
Emulation von vom Betriebssystem bereitgestellten Programmen: Insbesondere JCL-gesteuerte Batches erwarten in ihrer Standardumgebung die Fähigkeit, eine Vielzahl von Programmen zur Bearbeitung von Dateien und Datenbanken aufrufen zu können.
SORTDFSORTIDCAMSZu den Beispielen gehören/oder. Zu diesem Zweck werden Java-Programme bereitgestellt, die ein solches Verhalten reproduzieren und mit den gleichen Konventionen wie die älteren Programme aufgerufen werden können. -
„Treiber“, bei denen es sich um spezialisierte Programme handelt, die vom Ausführungsframework oder der Middleware als Einstiegspunkte bereitgestellt werden. Ein Beispiel ist
CBLTDLI, auf welche COBOL-Programme, die in der IMS-Umgebung ausgeführt werden, angewiesen sind, um auf IMS-bezogene Dienste (IMS-Datenbank, Benutzerdialog über MFS usw.) zuzugreifen.
Registrierung der Programme
Um an diesen Konstrukten, Frameworks und Diensten teilzuhaben und diese zu nutzen, folgen Java-Programme, die aus älteren Versionen modernisiert wurden, einer bestimmten Struktur, die unter dokumentiert ist. AWS Transformation für die Mainframe-Struktur einer modernisierten Anwendung Beim Start sammelt AWS Transform for Mainframe Runtime all diese Programme in einer gemeinsamen „Programmregistrierung“, sodass sie anschließend aufgerufen (und sich gegenseitig aufgerufen) werden können. Die Programmregistrierung bietet lockere Kopplungen und Möglichkeiten der Zerlegung (da Programme, die sich gegenseitig aufrufen, nicht gleichzeitig modernisiert werden müssen).
Ausführungsumgebungen
Häufig anzutreffende ältere Umgebungen und Choreografien sind verfügbar:
-
JCL-gesteuerte Batches können nach der Modernisierung auf Java-Programme und Groovy-Skripte synchron (blockierend) oder asynchron (getrennt) gestartet werden. Im letzteren Fall kann ihre Ausführung über REST-Endpunkte überwacht werden.
-
Ein AWS Transform for Mainframe-Subsystem bietet eine Ausführungsumgebung, die CICS ähnelt, und zwar durch:
-
einen Einstiegspunkt, der zum Starten einer CICS-Transaktion und zum Ausführen der zugehörigen Programme verwendet wird, wobei die CICS-Choreographie der „Run-Levels“ eingehalten wird,
-
ein externer Speicher für Ressourcendefinitionen,
-
ein homogener Satz von Anweisungen zur fließenden APIs Wiedergabe
EXEC CICSvon Java-Anweisungen, -
eine Reihe von austauschbaren Klassen, die CICS-Dienste wie Temporary Storage Queues, Temporary Data Queues oder Dateizugriff reproduzieren (in der Regel sind mehrere Implementierungen verfügbar, wie Amazon Managed Service für Apache Flink, Amazon Simple Queue Service oder RabbitMQ für TD Queues),
-
Für benutzerorientierte Anwendungen wurde das BMS-Bildschirmbeschreibungsformat zu einer Angular-Webanwendung modernisiert, und der entsprechende „Pseudo-Konversationsdialog“ wird unterstützt.
-
-
In ähnlicher Weise bietet ein anderes Subsystem eine auf IMS-Nachrichten basierende Choreographie und unterstützt die Modernisierung von Benutzeroberflächenbildschirmen im MFS-Format.
-
Darüber hinaus ermöglicht ein drittes Subsystem die Ausführung von Programmen in einer iSeries-ähnlichen Umgebung, einschließlich der Modernisierung von DSPF-spezifischen (Display File) -spezifischen Bildschirmen.
All diese Umgebungen bauen auf gängigen Diensten auf Betriebssystemebene auf, wie z. B.:
-
die Emulation herkömmlicher Speicherzuweisungen und Layouts (Data Simplifier),
-
Thread-basierte Reproduktion der COBOL-Ausführung von „Run-Units“ und des Mechanismus zur Übergabe von Parametern (Anweisung),
CALL -
Emulation von flachen, verketteten, VSAM-Organisationen (mithilfe der Blusam-Bibliotheken) und GDG-Datensatzorganisationen,
-
Zugriff auf Datenspeicher wie RDBMS (Statements).
EXEC SQL
Staatenlosigkeit und Umgang mit Sitzungen
Ein wichtiges Merkmal von AWS Transform for Mainframe Runtime besteht darin, Hochverfügbarkeits- (HA) und horizontale Skalierbarkeitsszenarien bei der Ausführung modernisierter Programme zu ermöglichen.
Der Eckpfeiler hierfür ist Staatenlosigkeit. Ein wichtiges Beispiel dafür ist die Handhabung von HTTP-Sitzungen.
Behandlung von Sitzungen
Da Tomcat webbasiert ist, sind die HTTP-Sitzungsbehandlung (wie sie von Tomcat und Spring bereitgestellt wird) und das statelose Design ein wichtiger Mechanismus dafür. Daher basiert das Konzept der Staatenlosigkeit auf folgenden Grundsätzen:
-
Benutzer stellen eine Verbindung über HTTPS her,
-
Anwendungsserver werden hinter einem Load Balancer bereitgestellt,
-
Wenn ein Benutzer zum ersten Mal eine Verbindung zur Anwendung herstellt, wird diese authentifiziert und der Anwendungsserver erstellt eine Kennung (normalerweise in einem Cookie)
-
Diese Kennung wird als Schlüssel verwendet, um den Benutzerkontext in einem to/from externen Cache (Datenspeicher) zu speichern und abzurufen.
Die Cookieverwaltung erfolgt automatisch durch das AWS Transform for Mainframe-Framework und den zugrunde liegenden Tomcat-Server. Dies ist für den Benutzer transparent. Der Internetbrowser des Benutzers verwaltet dies automatisch.
Die Gapwalk-Webanwendung kann den Sitzungsstatus (den Kontext) in verschiedenen Datenspeichern speichern:
-
Amazon ElastiCache (Redis OSS)
-
Redis-Cluster
-
in der Speicherzuweisung (nur für Entwicklungs- und Standalone-Umgebungen, nicht für HA geeignet).
Hohe Verfügbarkeit und Staatenlosigkeit
Allgemeiner ausgedrückt ist Zustandslosigkeit ein Grundprinzip des AWS Transform for Mainframe-Frameworks: Die meisten nichttransienten Zustände, die zur Reproduktion des Verhaltens älterer Programme erforderlich sind, werden nicht auf den Anwendungsservern gespeichert, sondern über eine externe, gemeinsame „zentrale Informationsquelle“ gemeinsam genutzt.
Beispiele für solche Zustände sind die temporären Speicherwarteschlangen oder Ressourcendefinitionen von CICS, und typische externe Speicher für diese sind Redis-kompatible Server oder relationale Datenbanken.
Dieses Design führt in Kombination mit Lastenausgleich und gemeinsam genutzten Sitzungen dazu, dass die meisten benutzerseitigen Dialoge (OLTP, „Online Transactional Processing“) auf mehrere „Knoten“ (hier Tomcat-Instanzen) verteilt werden können.
Tatsächlich kann ein Benutzer eine Transaktion auf einem beliebigen Server ausführen und es ist ihm egal, ob der nächste Transaktionsaufruf auf einem anderen Server ausgeführt wird. Wenn dann ein neuer Server gestartet wird (aufgrund von Auto Scaling oder um einen fehlerhaften Server zu ersetzen), können wir garantieren, dass jeder erreichbare und fehlerfreie Server die Transaktion wie erwartet mit den richtigen Ergebnissen ausführen kann (erwarteter Rückgabewert, erwartete Datenänderung in der Datenbank usw.).
