アプローチ 3：メッセージキューを使用してのデカップル

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

このアプローチは、次の場合を使用することをお勧めします：

• メインフレームに存在するアプリケーションは、メッセージキューを介してクラウド内の移行されたアプリケーションと通信できます。

• プログラム AB.1 の複数のコピー (前の 2 つのアプローチと同様に、オンプレミスのコピーとクラウドコピーなど) は維持できません。

• キューイング・アーキテクチャ・パターンは、メインフレームに存在するアプリケーションのビジネス要件を満たします。これは、既存のアプリケーションの再構築を伴うためです。

• 最初の Wave の一部ではないアプリケーションは、クラウドに移行するのに、より長い時間 (6 か月以上) 必要とします。

さまざまなウェーブでのアプリケーションの移行

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

この方法を使用している場合は、これらの手順に従います。

1. アプリケーション B がオンプレミスに常駐している間、（リファクタリング）アプリケーション A と関連するプログラムをクラウドに移行します。

2. アプリケーション A（クラウド内）をリファクタリングして、メッセージキューを介してアプリケーション B（オンプレミス）と通信します。

3. オンプレミスでアプリケーション B をリファクタリングして、共有プログラム AB.1 を、メッセージキューを介してアプリケーション A にメッセージを送信し、アプリケーション A からメッセージを受信するプロキシプログラムに置き換えます。

4. アプリケーション A が正常に移行されたら、オンプレミスアプリケーション A とそのコンポーネント (共有プログラムを含む) を廃止します。アプリケーション B とそのコンポーネントは引き続きオンプレミスに常駐し続けます。

5. 次の移行ウェーブセットでは、アプリケーション B とそのコンポーネントを移行します。疎結合キューイングアーキテクチャは、クラウド上のアプリケーション A と B の間のインターフェイスとして引き続き動作します。これにより、アプリケーション A に影響を与えることなく、アプリケーション B のリファクタリング作業が軽減されます。