

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# アプローチ 3: メッセージキューを使用してデカップリングします。
<a name="queue"></a>

この方法では、共有プログラム AB.1 が Java プログラムに変換され、アプリケーション A の一部としてクラウドに移行されます。メッセージキューは、クラウド中のリファクタリングされたアプリケーションとレガシーアプリケーションのオンプレミスのとの間のインターフェイスとして使用されます。このアプローチを使用すると、緊密に結合されたメインフレーム・アプリケーションをプロデューサとコンシューマに分割し、それらをよりモジュール化して独立して機能させることができます。追加の利点は、アプリケーションを異なる波で移行できることです。

このアプローチは、次の場合を使用することをお勧めします：
+ メインフレームに存在するアプリケーションは、メッセージキューを介してクラウド内の移行されたアプリケーションと通信できます。
+ プログラム AB.1 の複数のコピー (前の 2 つのアプローチと同様に、オンプレミスのコピーとクラウドコピーなど) は維持できません。
+ キューイング・アーキテクチャ・パターンは、メインフレームに存在するアプリケーションのビジネス要件を満たします。これは、既存のアプリケーションの再構築を伴うためです。
+ 最初の Wave の一部ではないアプリケーションは、クラウドに移行するのに、より長い時間 (6 か月以上) 必要とします。

## さまざまなウェーブでのアプリケーションの移行
<a name="queue-multi-wave"></a>

アプリケーションを同じ移行ウェーブにグループ化するには大きすぎる場合は、次の図に示すように複数のウェーブ中にアプリケーションを移行し、移行中にサービスの継続性を維持できます。このアプローチを用いて、アプリケーションをまとめてバンドルすることなく、段階的にアプリケーションを近代化できます。

 ![\[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 のリファクタリング作業が軽減されます。