翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# プログラムを共有するアプリケーション
次の図は、プログラム AB.1 という共有プログラムを実行するメインフレームアプリケーション A と B を示しています。このケースは、アプリケーション A と B が、共有サブプログラムを呼び出すプログラムを含んでいる場合にも適用されます。
![\[Mainframe applications that share programs\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/modernization-mainframe-decoupling-patterns/images/shared.png)
**Steps for analysis**
1. アプリケーション A と B、およびプログラム AB.1 を一緒に移行できるように、共有プログラム AB.1 の影響分析を実行します。解析を自動化する [Additional resources](resources.md) セクション中に記載されている検出ツールを使用することをお勧めします。
1. 影響分析に基づいて、プログラム AB.1 などの共有プログラムを使用する依存アプリケーションの数を特定します。
1. （レコメンデーション）ビジネスドメイン分析を実行して、共有プログラムをアプリケーションを用いてドメインに集約し、ドメインサービスのいずれかとして API として公開できるかどうかを判断します。
移行の準備として、次のいずれかの方法を使用して、アプリケーションをデカップリングできます。
+ [Use a standalone API](api.md)
+ [Use a shared library](library.md)
+ [Use a message queue](queue.md)
# アプローチ 1: スタンドアロン API を使用してデカップリングします。
この方法を使用する場合、共有 COBOL プログラム AB.1 を Java プログラムに変換することによって、スタンドアロン API をインスタンス化します。リファクタリング作業を最小限に抑えるために、 AWS パートナーが提供する自動リファクタリングツールを使用して ([「その他のリソース](resources.md)APIs を生成できます。一部のツールでは、Eclipse などの統合開発環境 (IDE) を使用して、選択されたプログラムから facade レイヤーを自動的に生成できます。
共有プログラムをスタンドアロンサービスとしてインスタンス化できる場合は、この方法をお勧めします。アプリケーション A と B の残りのコンポーネントは Java 全体にリファクタリングされ、クラウドに移行されます。アプリケーションを同じウェーブまたは異なるウェーブで移行できます。
## 同じウェーブでのアプリケーションの移行
次の図では、アプリケーション A と B が同じウェーブに移行されるようにグループ化されています。
![\[Migrating mainframe applications that share programs: using an standalone API and a single migration wave\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/modernization-mainframe-decoupling-patterns/images/shared-1-same.png)
スタンドアロン API を使用し、同じ Wave でアプリケーションを移行してコードをデカップリングしている場合は、次の手順に従います。
1. 両方のアプリケーションをそれぞれのプログラムでリファクタリングし、それらをクラウドに移行します。
1. 分析フェーズからの影響分析レポートを使用して、開発者とチームが共有プログラム AB.1 と呼ぶリファクタリングされたアプリケーションを特定できるようにします。共有プログラム AB.1 への内部プログラム呼び出しを、ネットワーク API 呼び出しと置き換えます。
1. 移行後、オンプレミスのメインフレームアプリケーションとそのコンポーネントを廃止します。
## さまざまなウェーブでのアプリケーションの移行
アプリケーションを同じ移行ウェーブにグループ化するには大きすぎる場合は、次の図に示すように複数のウェーブ中にアプリケーションを移行し、移行中にサービスの継続性を維持できます。このアプローチを用いて、アプリケーションをまとめてバンドルすることなく、段階的にアプリケーションを近代化できます。アプリケーションを別々の Wave に移行すると、メインフレームで大きなコードを変更することなく、アプリケーションがデカップリングされます。
![\[Migrating mainframe applications that share programs: using an standalone API and multiple migration waves\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/modernization-mainframe-decoupling-patterns/images/shared-1-diff.png)
スタンドアロン API を使用し、異なるウェーブでアプリケーションを移行してコードをデカップリングしている場合は、次の手順に従います。
1. アプリケーション B がオンプレミスに常駐している間、（リファクタリング）アプリケーション A を関連するプログラムと共にクラウドに移行します。
1. アプリケーション A で、共有プログラム AB.1 の内部プログラム呼び出しを API 呼び出しに置き換えます。
1. アプリケーション B が引き続き動作できるように、プログラム AB.1 のコピーをメインフレームに保持します。
1. メインフレームでプログラム AB.1 の機能開発をフリーズします。この時点以降、すべての機能開発はクラウドのリファクタリングプログラム AB.1 で行われます。
1. アプリケーション A が正常に移行されたら、オンプレミスアプリケーションとそのコンポーネント (共有プログラムを除く) を廃止します。アプリケーション B とそのコンポーネント (共有プログラムを含む) は、引き続きオンプレミスに常駐し続けます。
1. 次の移行ウェーブセットでは、アプリケーション B とそのコンポーネントを移行します。移行されたリファクタリングプログラム AB.1 を呼び出して、アプリケーション B のリファクタリングの労力を減らすことができます。
# アプローチ 2: 共有ライブラリを使用してのデカップリング
この方法では、共有プログラム AB.1 は Java 共通ライブラリに変換され、移行用のアプリケーションとともにパッケージ化されます。共有プログラムがスタンドアロンサービスではなくサポートライブラリである場合は、この方法をお勧めします。
アプリケーション A と B の残りのコンポーネントは Java プログラムにリファクタリングされ、クラウドに移行されます。アプリケーションを同じウェーブまたは異なるウェーブで移行できます。
## 同じウェーブでのアプリケーションの移行
次の図では、アプリケーション A と B が同じウェーブに移行されるようにグループ化されています。
![\[Migrating mainframe applications that share programs: using a common library and a single migration wave\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/modernization-mainframe-decoupling-patterns/images/shared-2-same.png)
共有ライブラリを使用し、同じ Wave でアプリケーションを移行してコードをデカップリングする場合は、これらの手順に従います。
1. アプリケーション A と B を関連するプログラムを使用して Java にリファクタリングし、それらをクラウドに移行します。
1. フルマネージド型のソース管理サービスでアプリケーションのソースコードを維持します。共有プログラムを使用するチームは、プルリクエスト、ブランチ、マージを使用してコードの変更を共同作業でき、共有プログラムコードに加えられた変更を制御できます。
1. 移行後、オンプレミスのメインフレームアプリケーションとそのコンポーネントを廃止します。
## さまざまなウェーブでのアプリケーションの移行
アプリケーションを同じ移行ウェーブにグループ化するには大きすぎる場合は、次の図に示すように複数のウェーブ中にアプリケーションを移行し、移行中にサービスの継続性を維持できます。このアプローチを用いて、アプリケーションをまとめてバンドルすることなく、段階的にアプリケーションを近代化できます。アプリケーションを別々の Wave に移行すると、メインフレーム上で大きなコードを変更することなく、アプリケーションがデカップリングされます。
![\[Migrating mainframe applications that share programs: using a common library and multiple migration waves\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/modernization-mainframe-decoupling-patterns/images/shared-2-diff.png)
共有ライブラリを使用し、異なるウェーブでアプリケーションを移行することによってコードをデカップリングしている場合は、これらの手順に従います。
1. アプリケーション B がオンプレミスに常駐している間、（リファクタリング）アプリケーション A と関連するプログラムをクラウドに移行します。
1. アプリケーション B が引き続き動作できるように、プログラム AB.1 のコピーをメインフレームに保持します。
1. メインフレーム上でプログラム AB.1 の機能開発をフリーズします。この時点で、すべての機能開発はクラウド中のリファクタリングプログラム AB.1 で行われます。
1. プログラム AB.1 の新機能を開発する場合、将来の Wave でのアプリケーション B の移行をサポートするために、下位互換性を維持します。
1. アプリケーション A が正常に移行されたら、オンプレミスアプリケーションとそのコンポーネント (共有プログラムを除く) を廃止します。アプリケーション B とそのコンポーネント (共有プログラムを含む) は、引き続きオンプレミスに常駐し続けます。
1. 次の移行ウェーブセットでは、アプリケーション B とそのコンポーネントを移行します。アプリケーション B のリファクタリングの労力を減らすために、クラウド内のプログラム AB.1 の最新の共有ライブラリを使用できます。
# アプローチ 3: メッセージキューを使用してデカップリングします。
この方法では、共有プログラム AB.1 が Java プログラムに変換され、アプリケーション A の一部としてクラウドに移行されます。メッセージキューは、クラウド中のリファクタリングされたアプリケーションとレガシーアプリケーションのオンプレミスのとの間のインターフェイスとして使用されます。このアプローチを使用すると、緊密に結合されたメインフレーム・アプリケーションをプロデューサとコンシューマに分割し、それらをよりモジュール化して独立して機能させることができます。追加の利点は、アプリケーションを異なる波で移行できることです。
このアプローチは、次の場合を使用することをお勧めします：
+ メインフレームに存在するアプリケーションは、メッセージキューを介してクラウド内の移行されたアプリケーションと通信できます。
+ プログラム AB.1 の複数のコピー (前の 2 つのアプローチと同様に、オンプレミスのコピーとクラウドコピーなど) は維持できません。
+ キューイング・アーキテクチャ・パターンは、メインフレームに存在するアプリケーションのビジネス要件を満たします。これは、既存のアプリケーションの再構築を伴うためです。
+ 最初の Wave の一部ではないアプリケーションは、クラウドに移行するのに、より長い時間 (6 か月以上) 必要とします。
## さまざまなウェーブでのアプリケーションの移行
アプリケーションを同じ移行ウェーブにグループ化するには大きすぎる場合は、次の図に示すように複数のウェーブ中にアプリケーションを移行し、移行中にサービスの継続性を維持できます。このアプローチを用いて、アプリケーションをまとめてバンドルすることなく、段階的にアプリケーションを近代化できます。
![\[Migrating mainframe applications that share programs: using a message queue and multiple migration waves\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/modernization-mainframe-decoupling-patterns/images/shared-3-diff.png)
この方法を使用している場合は、これらの手順に従います。
1. アプリケーション B がオンプレミスに常駐している間、（リファクタリング）アプリケーション A と関連するプログラムをクラウドに移行します。
1. アプリケーション A（クラウド内）をリファクタリングして、メッセージキューを介してアプリケーション B（オンプレミス）と通信します。
1. オンプレミスでアプリケーション B をリファクタリングして、共有プログラム AB.1 を、メッセージキューを介してアプリケーション A にメッセージを送信し、アプリケーション A からメッセージを受信するプロキシプログラムに置き換えます。
1. アプリケーション A が正常に移行されたら、オンプレミスアプリケーション A とそのコンポーネント (共有プログラムを含む) を廃止します。アプリケーション B とそのコンポーネントは引き続きオンプレミスに常駐し続けます。
1. 次の移行ウェーブセットでは、アプリケーション B とそのコンポーネントを移行します。疎結合キューイングアーキテクチャは、クラウド上のアプリケーション A と B の間のインターフェイスとして引き続き動作します。これにより、アプリケーション A に影響を与えることなく、アプリケーション B のリファクタリング作業が軽減されます。