AWS 大型主機執行期高階架構的轉換 - AWS 大型主機現代化
AWS 大型主機執行期元件的轉換執行環境無狀態和工作階段處理高可用性和無狀態

AWS Mainframe Modernization Service （受管執行期環境體驗） 不再向新客戶開放。對於與 AWS Mainframe Modernization Service （受管執行期環境體驗） 類似的功能，探索 AWS Mainframe Modernization Service （自我管理體驗）。現有客戶可以繼續正常使用該服務。如需詳細資訊，請參閱AWS 大型主機現代化可用性變更。

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

AWS 大型主機執行期高階架構的轉換

作為將舊版程式現代化為 Java 之大型主機解決方案 AWS 轉換的一部分，適用於大型主機執行期的 AWS Transform 透過提供舊版建構和程式程式碼組織標準化的程式庫，為現代化應用程式提供統一、以 REST 為基礎的進入點，以及此類應用程式的執行架構。

這類現代化應用程式是將大型主機和中階程式 （在下列文件中稱為「舊版」) 現代化為 Web 架構之大型主機自動重構 AWS 轉換程序的結果。

大型主機執行期目標的 AWS 轉換是複製舊版程式行為 （異功能）、效能 （與程式執行時間和資源耗用量相關），以及 Java 開發人員維護現代化程式的簡易性，不過會使用熟悉的環境和慣用語，例如 tomcat、Spring、getters/setters、流利 APIs。

AWS 大型主機執行期元件的轉換

大型主機執行期環境的 AWS 轉換由兩種元件組成：

  • 一組 Java 程式庫 (jar 檔案） 通常參考為「共用資料夾」，並提供舊版建構和陳述式。

  • 一組 Web 應用程式 (war 檔案），其中包含 Spring 型 Web 應用程式，為現代化程式提供一組常見的架構和服務。

以下各節詳細說明這兩個元件的角色。

AWS 大型主機程式庫的轉換

大型主機程式庫的 AWS 轉換是一組 jar 檔案，存放在新增至標準 tomcat classpath 的shared/子資料夾中，以便讓所有現代化 Java 程式都能使用。他們的目標是提供 Java 程式設計環境中原生且不易使用的功能，但傳統開發環境的典型功能。這些功能會以盡可能熟悉的方式公開給 Java 開發人員 (getters/setters、類別型、流暢APIs)。一個重要的範例是 Data Simplifier 程式庫，它為 Java 程式提供舊版記憶體配置和操作建構 （以 COBOL、PL1 或 RPG 語言出現）。這些 jar 是從舊版程式產生的現代化 Java 程式碼的核心相依性。如需 Data Simplifier 的詳細資訊，請參閱 什麼是大型主機 AWS Transform 中的資料簡化程式。

Web 應用程式

Web Application Archives (WARs) 是將程式碼和應用程式部署到 tomcat 應用程式伺服器的標準方式。做為大型主機執行期 AWS 轉換一部分提供的執行架構，旨在提供一組可重現舊版環境和交易監控 (JCL 批次、CICS、IMS...) 的執行架構，以及相關聯的必要服務。

最重要的是 gapwalk-application（通常簡稱為「Gapwalk」)，它提供一組統一的 REST 型進入點來觸發和控制交易、程式和批次執行。如需詳細資訊，請參閱AWS 大型主機執行期 APIs轉換。

此 Web 應用程式會配置 Java 執行緒和資源，以便在其設計內容中執行現代化程式。以下章節會詳細說明這類重現環境的範例。

其他 Web 應用程式會新增至執行環境 （更精確地說，是以下所述的「程式登錄」) 程式，模擬舊版程式可用的程式，以及可從中呼叫的程式。其中兩個重要的類別包括：

  • 模擬作業系統提供的程式：JCL 驅動的批次尤其預期能夠呼叫各種檔案和資料庫控制程式，作為其標準環境的一部分。範例包括 SORT/DFSORT 或 IDCAMS。為此，Java 程式提供重現這類行為的程式，並且可以使用與舊版程序相同的慣例進行呼叫。

  • 「驅動程式」，這是執行架構或中介軟體提供的特殊程式，做為進入點。範例為 CBLTDLI，在 IMS 環境中執行的 COBOL 程式取決於存取 IMS 相關服務 (IMS 資料庫、透過 MFS 的使用者對話方塊等）。

程式登錄檔

為了參與並利用這些建構、架構和服務，從舊版的 Java 程式進行現代化，遵循 中記錄的特定結構AWS 現代化應用程式大型主機結構的轉換。啟動時，大型主機執行期的 AWS 轉換會在常見的「程式登錄檔」中收集所有此類程式，以便之後可以叫用它們 （和呼叫彼此）。程式登錄檔提供鬆散耦合和分解的可能性 （因為彼此呼叫的程式不必同時進行現代化）。

執行環境

提供經常遇到的舊版環境和編排：

  • JCL 驅動的批次一旦現代化為 Java 程式和 Groovy 指令碼，即可以同步 （封鎖） 或非同步 （刪除） 方式啟動。在後一種情況下，可以透過 REST 端點監控其執行。

  • 大型主機子系統的 AWS 轉換透過下列方式提供類似 CICS 的執行環境：

    • 一個進入點，用於啟動 CICS 交易並執行相關聯的程式，同時遵守 CICS「執行層級」編排，

    • 資源定義的外部儲存、

    • 一組同質的 Java 流利 APIs重新產生EXEC CICS陳述式，

    • 一組可重新產生 CICS 服務的可插拔類別，例如暫存儲存佇列、暫存資料佇列或檔案存取 （通常提供多個實作，例如 Amazon Managed Service for Apache Flink、Amazon Simple Queue Service 或 RabbitMQ for TD Queues)。

    • 對於面向使用者的應用程式，BMS 螢幕描述格式會現代化為 Angular Web 應用程式，並支援對應的「虛擬融合」對話方塊。

  • 同樣地，另一個子系統提供以 IMS 訊息為基礎的編排，並支援以 MFS 格式現代化 UI 畫面。

  • 此外，第三個子系統允許在類似 iSeries 的環境中執行程式，包括DSPF （顯示檔案） 指定畫面的現代化。

所有這些環境都以常見的作業系統層級服務為基礎，例如：

  • 模擬舊版記憶體配置和配置 (資料簡化程式)，

  • Java 執行緒式 COBOL「執行單位」執行的重製和傳遞機制的參數 (CALL 陳述式），

  • 模擬平面、串連、VSAM （透過 Blusam 程式庫集） 和 GDG 資料集組織，

  • 存取資料存放區，例如 RDBMS (EXEC SQL 陳述式）。

無狀態和工作階段處理

大型主機執行期 AWS 轉換的重要功能是在執行現代化程式時啟用高可用性 (HA) 和水平可擴展性案例。

其基石是無狀態，這是 HTTP 工作階段處理的重要範例。

工作階段處理

Tomcat 以 Web 為基礎，這是 HTTP 工作階段處理 （如 tomcat 和 Spring 所提供） 和無狀態設計的重要機制。因此，無狀態設計是以下列項目為基礎：

  • 使用者透過 HTTPS 連線，

  • 應用程式伺服器會部署在負載平衡器後方，

  • 當使用者第一次連線到應用程式時，將會進行身分驗證，而應用程式伺服器將會建立識別符 （通常在 Cookie 內）

  • 此識別符將用作金鑰，以儲存和擷取使用者內容至外部快取 （資料存放區） 或從中擷取內容。

Cookie 管理由大型主機架構的 AWS Transform 和基礎 tomcat 伺服器自動完成，這對於使用者來說是透明的。使用者網際網路瀏覽器會自動管理此項目。

Gapwalk Web 應用程式可能會在各種資料存放區中存放工作階段狀態 （內容）：

  • Amazon ElastiCache (Redis OSS)

  • Redis 叢集

  • 在記憶體映射中 （僅適用於開發和獨立環境，不適用於 HA)。

高可用性和無狀態

更普遍地說，大型主機架構 AWS 轉換的設計原則是無狀態：大多數需要的非暫時性狀態不會存放在應用程式伺服器中，而是透過外部常見的「單一事實來源」共用。

這類狀態的範例包括 CICS 的暫時儲存佇列或資源定義，而這些狀態的一般外部儲存是與 Redis 相容的伺服器或關聯式資料庫。

此設計結合負載平衡和共用工作階段，會導致大多數面向使用者的對話方塊 (OLTP、「線上交易處理」) 可在多個「節點」（此處為 tomcat 執行個體） 之間分佈。

事實上，使用者可以在任何伺服器上執行交易，而不在意下一個交易呼叫是否在不同伺服器上執行。然後，當產生新的伺服器時 （由於自動擴展或取代運作狀態不佳的伺服器），我們可以保證任何可連線且運作狀態良好的伺服器都能以適當的結果執行交易 （預期的傳回值、預期的資料庫資料變更等）。