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.
# Anwendungen, die Programme gemeinsam nutzen
Das folgende Diagramm zeigt die Mainframe-Anwendungen A und B, die ein gemeinsam genutztes Programm namens Programm AB.1 ausführen. Dieser Fall gilt auch, wenn die Anwendungen A und B Programme enthalten, die gemeinsam genutzte Unterprogramme aufrufen.
![\[Mainframe applications that share programs\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/modernization-mainframe-decoupling-patterns/images/shared.png)
**Schritte zur Analyse**
1. Führen Sie eine Auswirkungsanalyse des gemeinsam genutzten Programms AB.1 durch, sodass Sie die Anwendungen A und B migrieren und AB.1 zusammen programmieren können. Wir empfehlen, die im Abschnitt [Zusätzliche Ressourcen](resources.md) aufgeführten Erkennungstools zu verwenden, um die Analyse zu automatisieren.
1. Ermitteln Sie anhand der Wirkungsanalyse die Anzahl der abhängigen Anwendungen, die gemeinsam genutzte Programme wie das Programm AB.1 verwenden.
1. (Empfohlen) Führen Sie eine Geschäftsdomänenanalyse durch, um festzustellen, ob das gemeinsam genutzte Programm zu einer Domäne mit Anwendungen zusammengefasst und als API als einer der Domänendienste bereitgestellt werden kann.
Sie können einen der folgenden Ansätze verwenden, um die Anwendungen zur Vorbereitung der Migration zu entkoppeln:
+ [Verwenden Sie eine eigenständige API](api.md)
+ [Verwenden Sie eine gemeinsam genutzte Bibliothek](library.md)
+ [Verwenden Sie eine Nachrichtenwarteschlange](queue.md)
# Ansatz 1: Entkoppeln Sie mithilfe einer eigenständigen API
Wenn Sie diesen Ansatz verwenden, instanziieren Sie eine eigenständige API, indem Sie das gemeinsam genutzte COBOL-Programm AB.1 in ein Java-Programm konvertieren. Um den Refactoring-Aufwand zu minimieren, können Sie automatisierte Refactoring-Tools verwenden, die von AWS Partnern bereitgestellt werden (siehe Abschnitt [Zusätzliche Ressourcen), um das Netzwerk für das Programm](resources.md) zu generieren. APIs Einige Tools können mithilfe einer integrierten Entwicklungsumgebung (IDE) wie Eclipse automatisch eine Fassadenebene aus dem ausgewählten Programm generieren.
Wir empfehlen diesen Ansatz, wenn das gemeinsam genutzte Programm als eigenständiger Dienst instanziiert werden kann. Die übrigen Komponenten der Anwendungen A und B werden in Java als Ganzes überarbeitet und in die Cloud migriert. Sie können die Anwendungen in derselben Welle oder in verschiedenen Wellen migrieren.
## Anwendungen in derselben Welle migrieren
In der folgenden Abbildung sind die Anwendungen A und B so gruppiert, dass sie in derselben Welle migriert werden.
![\[Migrating mainframe applications that share programs: using an standalone API and a single migration wave\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/modernization-mainframe-decoupling-patterns/images/shared-1-same.png)
Wenn Sie Ihren Code entkoppeln, indem Sie eine eigenständige API verwenden und Anwendungen in derselben Welle migrieren, gehen Sie wie folgt vor:
1. Refaktorieren Sie beide Anwendungen mit ihren jeweiligen Programmen und migrieren Sie sie in die Cloud.
1. Verwenden Sie den Wirkungsanalysebericht aus der Analysephase, um Entwicklern und Teams dabei zu helfen, die umgestalteten Anwendungen zu identifizieren, die das gemeinsame Programm AB.1 nennen. Ersetzen Sie den internen Programmaufruf des gemeinsam genutzten Programms AB.1 durch Netzwerk-API-Aufrufe.
1. Nach der Migration sollten Sie die lokalen Mainframe-Anwendungen und ihre Komponenten außer Betrieb nehmen.
## Anwendungen in verschiedenen Wellen migrieren
Wenn Anwendungen zu groß sind, um in derselben Migrationswelle zusammengefasst zu werden, können Sie sie in mehreren Wellen migrieren, wie in der folgenden Abbildung dargestellt, und die Servicekontinuität während der Migration aufrechterhalten. Mit diesem Ansatz können Sie Ihre Anwendungen phasenweise modernisieren, ohne sie zu bündeln. Durch die Migration Ihrer Anwendungen in separaten Wellen werden sie entkoppelt, ohne dass wesentliche Codeänderungen auf dem Mainframe erforderlich sind.
![\[Migrating mainframe applications that share programs: using an standalone API and multiple migration waves\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/modernization-mainframe-decoupling-patterns/images/shared-1-diff.png)
Wenn Sie Ihren Code entkoppeln, indem Sie eine eigenständige API verwenden und Anwendungen in verschiedenen Wellen migrieren, gehen Sie wie folgt vor:
1. Migrieren (refaktorieren) Sie Anwendung A mit den zugehörigen Programmen in die Cloud, während sich Anwendung B weiterhin lokal befindet.
1. Ersetzen Sie in Anwendung A den internen Programmaufruf des gemeinsam genutzten Programms AB.1 durch einen API-Aufruf.
1. Behalten Sie eine Kopie des Programms AB.1 auf dem Mainframe bei, damit Anwendung B weiter betrieben werden kann.
1. Frieren Sie die Funktionsentwicklung des Programms AB.1 auf dem Mainframe ein. Nach diesem Zeitpunkt wird die gesamte Feature-Entwicklung im umgestalteten Programm AB.1 in der Cloud stattfinden.
1. Nachdem Anwendung A erfolgreich migriert wurde, sollten Sie die lokale Anwendung und ihre Komponenten (mit Ausnahme des gemeinsam genutzten Programms) außer Betrieb nehmen. Anwendung B und ihre Komponenten (einschließlich des gemeinsam genutzten Programms) befinden sich weiterhin lokal.
1. Migrieren Sie in den nächsten Migrationswellen Anwendung B und ihre Komponenten. Sie können das migrierte, umgestaltete Programm AB.1 aufrufen, um den Refactoring-Aufwand für Anwendung B zu reduzieren.
# Ansatz 2: Entkoppeln mithilfe einer gemeinsam genutzten Bibliothek
Bei diesem Ansatz wird das gemeinsam genutzte Programm AB.1 in eine gemeinsame Java-Bibliothek umgewandelt und zusammen mit den Anwendungen für die Migration verpackt. Wir empfehlen diesen Ansatz, wenn es sich bei dem gemeinsam genutzten Programm um eine unterstützende Bibliothek und nicht um einen eigenständigen Dienst handelt.
Die übrigen Komponenten der Anwendungen A und B werden in Java-Programme umgestaltet und in die Cloud migriert. Sie können die Anwendungen in derselben Welle oder in verschiedenen Wellen migrieren.
## Anwendungen in derselben Welle migrieren
In der folgenden Abbildung sind die Anwendungen A und B so gruppiert, dass sie in derselben Welle migriert werden.
![\[Migrating mainframe applications that share programs: using a common library and a single migration wave\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/modernization-mainframe-decoupling-patterns/images/shared-2-same.png)
Wenn Sie Ihren Code entkoppeln, indem Sie eine gemeinsam genutzte Bibliothek verwenden und Anwendungen in derselben Welle migrieren, gehen Sie wie folgt vor:
1. Refaktorieren Sie die Anwendungen A und B mit den zugehörigen Programmen in Java und migrieren Sie sie in die Cloud.
1. Pflegen Sie den Quellcode der Anwendungen in einem vollständig verwalteten Quellcodeverwaltungsdienst. Die Teams, die das gemeinsam genutzte Programm verwenden, können mithilfe von Pull-Requests, Branching und Merging gemeinsam an Codeänderungen arbeiten und die Änderungen am gemeinsam genutzten Programmcode kontrollieren.
1. Nach der Migration sollten Sie die lokalen Mainframe-Anwendungen und ihre Komponenten außer Betrieb nehmen.
## Anwendungen in verschiedenen Wellen migrieren
Wenn Anwendungen zu groß sind, um in derselben Migrationswelle zusammengefasst zu werden, können Sie sie in mehreren Wellen migrieren, wie in der folgenden Abbildung dargestellt, und die Servicekontinuität während der Migration aufrechterhalten. Mit diesem Ansatz können Sie Ihre Anwendungen phasenweise modernisieren, ohne sie zu bündeln. Durch die Migration Ihrer Anwendungen in separaten Wellen werden sie entkoppelt, ohne dass wesentliche Codeänderungen auf dem Mainframe erforderlich sind.
![\[Migrating mainframe applications that share programs: using a common library and multiple migration waves\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/modernization-mainframe-decoupling-patterns/images/shared-2-diff.png)
Wenn Sie Ihren Code entkoppeln, indem Sie eine gemeinsam genutzte Bibliothek verwenden und Anwendungen in verschiedenen Wellen migrieren, gehen Sie wie folgt vor:
1. Migrieren (refaktorieren) Sie Anwendung A mit den zugehörigen Programmen in die Cloud, während sich Anwendung B weiterhin lokal befindet.
1. Bewahren Sie eine Kopie von Programm AB.1 auf dem Mainframe auf, damit Anwendung B weiter betrieben werden kann.
1. Frieren Sie die Funktionsentwicklung des Programms AB.1 auf dem Mainframe ein. Zu diesem Zeitpunkt wird die gesamte Feature-Entwicklung im umgestalteten Programm AB.1 in der Cloud stattfinden.
1. Achten Sie bei der Entwicklung neuer Funktionen für Programm AB.1 auf Abwärtskompatibilität, um die Migration von Anwendung B in future Wellen zu unterstützen.
1. Nachdem Anwendung A erfolgreich migriert wurde, sollten Sie die lokale Anwendung und ihre Komponenten (mit Ausnahme des gemeinsam genutzten Programms) außer Betrieb nehmen. Anwendung B und ihre Komponenten (einschließlich des gemeinsam genutzten Programms) befinden sich weiterhin lokal.
1. Migrieren Sie in den nächsten Migrationswellen Anwendung B und ihre Komponenten. Sie können die neueste gemeinsam genutzte Bibliothek des Programms AB.1 in der Cloud verwenden, um den Refactoring-Aufwand für Anwendung B zu reduzieren.
# Ansatz 3: Entkopplung mithilfe einer Nachrichtenwarteschlange
Bei diesem Ansatz wird das gemeinsam genutzte Programm AB.1 in ein Java-Programm umgewandelt und als Teil von Anwendung A in die Cloud migriert. Eine Nachrichtenwarteschlange wird als Schnittstelle zwischen der umgestalteten Anwendung in der Cloud und der Legacy-Anwendung vor Ort verwendet. Mit diesem Ansatz können Sie eng miteinander verbundene Mainframe-Anwendungen in Hersteller und Verbraucher aufteilen und sie modularer gestalten, sodass sie unabhängig voneinander funktionieren können. Der zusätzliche Vorteil besteht darin, dass Sie die Anwendungen in verschiedenen Wellen migrieren können.
Wir empfehlen Ihnen, diesen Ansatz zu verwenden, wenn:
+ Anwendungen, die sich auf dem Mainframe befinden, können über eine Nachrichtenwarteschlange mit den migrierten Anwendungen in der Cloud kommunizieren.
+ Mehrere Kopien des Programms AB.1 (z. B. eine lokale Kopie und eine Cloud-Kopie, wie bei den beiden vorherigen Ansätzen) können nicht verwaltet werden.
+ Das Queuing-Architekturmuster erfüllt die Geschäftsanforderungen für die Anwendungen, die sich auf dem Mainframe befinden, da es eine Neuarchitektur der vorhandenen Anwendungen beinhaltet.
+ Die Anwendungen, die nicht Teil der ersten Welle sind, benötigen eine längere Zeit (sechs Monate oder länger), um in die Cloud migriert zu werden.
## Migration von Anwendungen in verschiedenen Wellen
Wenn Anwendungen zu groß sind, um in derselben Migrationswelle zusammengefasst zu werden, können Sie sie in mehreren Wellen migrieren, wie in der folgenden Abbildung dargestellt, und die Servicekontinuität während der Migration aufrechterhalten. Mit diesem Ansatz können Sie Ihre Anwendungen phasenweise modernisieren, ohne sie zu bündeln.
![\[Migrating mainframe applications that share programs: using a message queue and multiple migration waves\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/modernization-mainframe-decoupling-patterns/images/shared-3-diff.png)
Wenn Sie diesen Ansatz verwenden, gehen Sie wie folgt vor:
1. Migrieren (refaktorieren) Sie Anwendung A mit den zugehörigen Programmen in die Cloud, während sich Anwendung B weiterhin lokal befindet.
1. Refaktorieren Sie Anwendung A (in der Cloud) so, dass sie mit Anwendung B (lokal) über eine Nachrichtenwarteschlange kommuniziert.
1. Refaktorieren Sie Anwendung B vor Ort, um das gemeinsam genutzte Programm AB.1 durch ein Proxyprogramm zu ersetzen, das Nachrichten über die Nachrichtenwarteschlange an Anwendung A sendet und Nachrichten von Anwendung A empfängt.
1. Nachdem Anwendung A erfolgreich migriert wurde, sollten Sie die lokale Anwendung A und ihre Komponenten (einschließlich des gemeinsam genutzten Programms) außer Betrieb nehmen. Anwendung B und ihre Komponenten befinden sich weiterhin lokal.
1. Migrieren Sie in den nächsten Migrationswellen Anwendung B und ihre Komponenten. Die lose gekoppelte Warteschlangenarchitektur fungiert weiterhin als Schnittstelle zwischen den Anwendungen A und B in der Cloud. Dadurch wird der Refactoring-Aufwand für Anwendung B reduziert, ohne dass sich dies auf Anwendung A auswirkt.