本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 共用程式的應用程式
<a name="shared"></a>

下圖說明執行稱為 AB.1 程式的共用程式的大型主機應用程式 A 和 B。當應用程式 A 和 B 包含呼叫共用子程式的程式時，此案例也適用。

 ![\[Mainframe applications that share programs\]](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/modernization-mainframe-decoupling-patterns/images/shared.png) 

**分析步驟**

1. 執行共用程式 AB.1 的影響分析，以便您可以一起遷移應用程式 A 和 B，以及程式 AB.1。我們建議您使用[其他資源](resources.md)區段中列出的探索工具來自動化分析。

1. 根據影響分析，識別使用程式 AB.1 等共用程式的相依應用程式數量。

1. （建議） 完成商業網域分析，以判斷共用的程式是否可以彙總到具有應用程式的網域，並以 API 的形式公開為網域服務之一。

您可以使用下列其中一種方法來解耦應用程式，以準備遷移：
+ [使用獨立 API](api.md)
+ [使用共用程式庫](library.md)
+ [使用訊息佇列](queue.md)

# 方法 1：使用獨立 API 進行解耦
<a name="api"></a>

當您使用此方法時，您可以將共用的 COBOL 程式 AB.1 轉換為 Java 程式，以執行個體化獨立 API。若要將重構工作降至最低，您可以使用 AWS 合作夥伴提供的自動重構工具 （請參閱[其他資源](resources.md)區段） 來產生程式的網路 APIs。某些工具可以使用整合式開發環境 (IDE)，例如 Eclipse，從選取的程式自動產生外觀圖層。

我們建議在共用程式可以做為獨立服務進行執行個體化時採用此方法。應用程式 A 和 B 的其餘元件會重構為 Java 整體，並遷移至雲端。您可以在相同波或不同波中遷移應用程式。

## 在同一波中遷移應用程式
<a name="api-same-wave"></a>

在下圖中，應用程式 A 和 B 會分組，以在同一波中遷移。

 ![\[Migrating mainframe applications that share programs: using an standalone API and a single migration wave\]](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/modernization-mainframe-decoupling-patterns/images/shared-1-same.png) 

如果您使用獨立 API 和在同一波中遷移應用程式來解耦程式碼，請遵循下列步驟：

1. 使用各自的程式來重構這兩個應用程式，並將其遷移至雲端。

1. 使用分析階段的影響分析報告，協助開發人員和團隊識別呼叫共用程式 AB.1 的重構應用程式。使用網路 API 呼叫取代對共用程式 AB.1 的內部程式呼叫。

1. 遷移之後，請淘汰內部部署大型主機應用程式及其元件。

## 在不同的波中遷移應用程式
<a name="api-multi-wave"></a>

當應用程式太大而無法分組到相同的遷移波時，您可以多個波遷移它們，如下圖所示，並在遷移期間保持服務連續性。透過此方法，您可以分階段現代化您的應用程式，而無需綁定在一起。在不同的波中遷移應用程式會解耦應用程式，而不需要在大型主機上進行重大的程式碼變更。

 ![\[Migrating mainframe applications that share programs: using an standalone API and multiple migration waves\]](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/modernization-mainframe-decoupling-patterns/images/shared-1-diff.png) 

如果您使用獨立 API 和在不同波中遷移應用程式來解耦程式碼，請遵循下列步驟：

1. 將應用程式 A 及其相關聯的程式遷移 （重構） 至雲端，同時應用程式 B 繼續駐留在內部部署。

1. 在應用程式 A 中，將對共用程式 AB.1 的內部程式呼叫取代為 API 呼叫。

1. 在大型主機上保留程式 AB.1 的副本，以便應用程式 B 可以繼續操作。

1. 凍結大型主機上程式 AB.1 的功能開發。此時，所有功能開發都將在雲端的重構程式 AB.1 中進行。

1. 成功遷移應用程式 A 後，請淘汰現場部署應用程式及其元件 （共用程式除外）。應用程式 B 及其元件 （包括共用程式） 會繼續駐留在內部部署。

1. 在下一組遷移波中，遷移應用程式 B 及其元件。您可以呼叫遷移的重構程式 AB.1，以減少應用程式 B 的重構工作。

# 方法 2：使用共用程式庫進行解耦
<a name="library"></a>

在此方法中，共用程式 AB.1 會轉換為 Java 通用程式庫，並封裝在應用程式以進行遷移。當共用程式是支援程式庫而非獨立服務時，我們建議使用此方法。

應用程式 A 和 B 的其餘元件會重構為 Java 程式，並遷移至雲端。您可以在相同波或不同波中遷移應用程式。

## 在同一波中遷移應用程式
<a name="library-same-wave"></a>

在下圖中，應用程式 A 和 B 會分組，以在同一波中遷移。

 ![\[Migrating mainframe applications that share programs: using a common library and a single migration wave\]](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/modernization-mainframe-decoupling-patterns/images/shared-2-same.png) 

如果您使用共用程式庫和在相同批次中遷移應用程式來解耦程式碼，請遵循下列步驟：

1. 將應用程式 A 和 B 及其相關聯的程式重構為 Java，並將其遷移至雲端。

1. 在全受管來源控制服務中維護應用程式的原始碼。使用共用程式的團隊可以使用提取請求、分支和合併來協同處理程式碼變更，並可以控制對共用程式碼所做的變更。

1. 遷移之後，請淘汰內部部署大型主機應用程式及其元件。

## 在不同的波中遷移應用程式
<a name="library-multi-wave"></a>

當應用程式太大而無法分組到相同的遷移波時，您可以多個波遷移它們，如下圖所示，並在遷移期間保持服務連續性。透過此方法，您可以分階段現代化您的應用程式，而無需綁定在一起。在不同的波中遷移應用程式會解耦應用程式，而不需要在大型主機上進行重大的程式碼變更。

 ![\[Migrating mainframe applications that share programs: using a common library and multiple migration waves\]](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/modernization-mainframe-decoupling-patterns/images/shared-2-diff.png) 

如果您使用共用程式庫和在不同波中遷移應用程式來解耦程式碼，請遵循下列步驟：

1. 將應用程式 A 及其相關聯的程式遷移 （重構） 至雲端，同時應用程式 B 繼續駐留在內部部署。

1. 在大型主機上保留程式 AB.1 的副本，以便應用程式 B 可以繼續操作。

1. 凍結大型主機上程式 AB.1 的功能開發。此時，所有功能開發都將在雲端的重構程式 AB.1 中進行。

1. 為程式 AB.1 開發新功能時，請保持回溯相容性，以支援應用程式 B 在未來的遷移。

1. 成功遷移應用程式 A 後，請淘汰現場部署應用程式及其元件 （共用程式除外）。應用程式 B 及其元件 （包括共用程式） 會繼續駐留在內部部署。

1. 在下一組遷移波中，遷移應用程式 B 及其元件。您可以使用雲端中最新的共用程式庫 AB.1，以減少應用程式 B 的重構工作。

# 方法 3：使用訊息佇列進行解耦
<a name="queue"></a>

在此方法中，共享程式 AB.1 會轉換為 Java 程式，並遷移至雲端做為應用程式 A 的一部分。訊息佇列會用作雲端中重構應用程式與內部部署中舊版應用程式之間的界面。透過使用此方法，您可以將緊密聯結的大型主機應用程式分解為生產者和消費者，使它們更模組化，以便它們可以獨立運作。其他優點是您可以在不同的波中遷移應用程式。

我們建議您在下列情況下使用此方法：
+ 位於大型主機上的應用程式可以透過訊息佇列與雲端中的遷移應用程式進行通訊。
+ 無法維護程式 AB.1 的多個複本 （例如，內部部署複本和雲端複本，如先前兩種方法所示）。
+ 佇列架構模式符合大型主機上應用程式的商業需求，因為它涉及重新架構現有應用程式。
+ 不屬於第一波的應用程式需要更長的時間 (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/zh_tw/prescriptive-guidance/latest/modernization-mainframe-decoupling-patterns/images/shared-3-diff.png) 

如果您使用這種方法，請遵循下列步驟：

1. 將應用程式 A 及其相關聯的程式遷移 （重構） 至雲端，同時應用程式 B 繼續駐留在內部部署。

1. 重構應用程式 A （在雲端），透過訊息佇列與應用程式 B （內部部署） 通訊。

1. 重構現場部署的應用程式 B，將共用程式 AB.1 取代為透過訊息佇列傳送訊息至應用程式 A 並從中接收訊息的代理程式。

1. 成功遷移應用程式 A 後，請淘汰內部部署應用程式 A 及其元件 （包括共用程式）。應用程式 B 及其元件會繼續駐留在內部部署。

1. 在下一組遷移波中，遷移應用程式 B 及其元件。鬆散耦合的佇列架構會繼續做為雲端應用程式 A 和 B 之間的界面。這可減少應用程式 B 的重構工作，而不會影響應用程式 A。