AWS Mainframe Modernization Service (マネージドランタイム環境エクスペリエンス) は、新規のお客様に公開されなくなりました。 AWS Mainframe Modernization Service (マネージドランタイム環境エクスペリエンス) と同様の機能については、 AWS Mainframe Modernization Service (セルフマネージドエクスペリエンス) をご覧ください。既存のお客様は、通常どおりサービスを引き続き使用できます。詳細については、[AWS 「 Mainframe Modernization の可用性の変更](https://docs.aws.amazon.com/m2/latest/userguide/mainframe-modernization-availability-change.html)」を参照してください。
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# AWS メインフレームランタイムの高レベルアーキテクチャの変換
レガシープログラムを Java にモダナイズするための AWS Transform for mainframe ソリューションの一環として、 AWS Transform for mainframe Runtime は、レガシーコンストラクトとプログラムコード組織の標準化を提供するライブラリを通じて、モダナイズされたアプリケーション用の統合された REST ベースのエントリポイントと、そのようなアプリケーションの実行フレームワークを提供します。
このようなモダナイズされたアプリケーションは、メインフレームおよびミッドレンジプログラム (次のドキュメントでは「レガシー」と呼びます) をウェブベースのアーキテクチャにモダナイズするためのメインフレーム自動リファクタリングプロセスの AWS 変換の結果です。
AWS Transform for mainframe Runtime の目標は、従来のプログラムの動作 (同機能）、パフォーマンス (プログラムの実行時間とリソースの消費に関するもの）、Java 開発者によるモダナイズされたプログラムのメンテナンスのしやすさです。ただし、tomcat、Spring、getters/setters、fluent APIs などの使い慣れた環境とイディオムを使用しています。
**Topics**
+ [AWS メインフレームランタイムコンポーネントの変換](#ba-shared-architecture-components)
+ [実行環境](#ba-shared-architecture-environments)
+ [ステートレス性とセッション処理](#ba-shared-architecture-stateless)
+ [高可用性とステートレス性](#ba-shared-architecture-stateless-ha)
## AWS メインフレームランタイムコンポーネントの変換
AWS Transform for mainframe Runtime 環境は、次の 2 種類のコンポーネントで構成されています。
+ しばしば「共有フォルダ」と呼ばれ、従来の構造やステートメントを提供する java ライブラリ (jar ファイル) のセット。
+ モダナイズされたプログラムに共通のフレームワークとサービスを提供する、Spring ベースの一連のウェブアプリケーション (war ファイル)。
次のセクションでは、これらの両方のコンポーネントの役割について詳しく説明します。
### AWS メインフレームライブラリの変換
メインフレームライブラリの AWS 変換は、モダナイズされたすべての Java プログラムで使用できるように、標準の tomcat クラスパスに追加された`shared/`サブフォルダに保存されている一連の jar ファイルです。これは Java プログラミング環境ではそのまま簡単に利用することはできませんが、従来の開発環境によくある機能を提供することを目的としています。これらの機能は、Java 開発者ができるだけ使い慣れた方法 (ゲッター/セッター、クラスベース、fluent API) で公開されています。重要な例としては、(COBOL、PL1、または RPG 言語に存在する) 従来のメモリレイアウトと操作コンストラクトを Java プログラムに提供する **Data Simplifier** ライブラリがあります。それらの jar は、レガシープログラムから生成されたモダナイズされた Java コードの主要な依存関係です。Data Simplifier の詳細については、「[Transform AWS for Mainframe のデータシンプリファイアとは](ba-shared-data.md)」を参照してください。
### ウェブアプリケーション
ウェブアプリケーションアーカイブ (WAR) は、コードとアプリケーションを tomcat アプリケーションサーバーにデプロイするための標準的な方法です。 AWS Transform for mainframe ランタイムの一部として提供されるものは、レガシー環境とトランザクションモニター (JCL バッチ、CICS、IMS...) および関連する必要なサービスを生成する一連の実行フレームワークを提供することを目指しています。
最も重要なのものは `gapwalk-application` (しばしば「Gapwalk」と略される) で、これはトランザクション、プログラム、バッチの実行をトリガーおよび制御するための REST ベースのエントリポイントの統合セットを提供します。詳細については、「[AWS メインフレームランタイム APIs変換](ba-runtime-endpoints.md)」を参照してください。
このウェブアプリケーションは Java 実行スレッドとリソースを割り当て、モダナイズされたプログラムを設計時のコンテキストで実行します。このような再現環境の例については、次のセクションで詳しく説明します。
他のウェブアプリケーションは、レガシープログラムから使用可能な、またはレガシープログラムから呼び出し可能なプログラムをエミュレートするプログラムを、実行環境 (より正確には、後述の「プログラムレジストリ」) に追加します。以下の、2 つの重要なカテゴリがあります。
+ OS が提供するプログラムのエミュレーション: JCL 駆動のバッチは、特に標準環境の一部としてさまざまなファイルやデータベースを操作するプログラムを呼び出せる必要があります。例には `SORT`/`DFSORT` または `IDCAMS` が含まれます。この目的のために、このような動作を再現し、従来のものと同じ規則を使用して呼び出し可能な Java プログラムが用意されています。
+ 「ドライバー」とは、実行フレームワークまたはミドルウェアがエントリポイントとして提供する特殊なプログラムです。1 つの例は `CBLTDLI` で、IMS 環境で実行される COBOL プログラムは、IMS 関連サービス (IMS DB、MFS を介したユーザーダイアログなど) へのアクセスに依存しています。
### プログラムレジストリ
これらのコンストラクト、フレームワーク、サービスに追加して活用するために、レガシープログラムからモダナイズされた Java プログラムは、[AWS モダナイズされたアプリケーションのメインフレーム構造の変換](ba-shared-structure.md) に記載されている特定の構造に準拠しています。起動時に、メインフレームランタイムの AWS 変換は、このようなプログラムをすべて共通の「プログラムレジストリ」に収集し、後で呼び出す (および相互に呼び出す) ことができるようにします。プログラムレジストリは疎結合であり、分解の可能性もあります (相互に呼び出すプログラムは同時にモダナイズする必要がないため)。
## 実行環境
よく見かけるレガシー環境やコレオグラフィは以下のとおりです。
+ JCL 駆動型バッチは Java プログラムと Groovy スクリプトにモダナイズされると、同期 (ブロッキング) または非同期 (デタッチ) で起動できます。後者の場合、その実行は REST エンドポイントを通じて監視できます。
+ メインフレームサブシステムの AWS 変換は、以下を通じて CICS と同様の実行環境を提供します。
+ CICS の「実行レベル」のコレオグラフィを順守しながら、CICS トランザクションを開始して関連プログラムを実行するために使用されるエントリポイント。
+ リソース定義用の外部ストレージ
+ `EXEC CICS` ステートメントを再現する同質の Java fluent API セット
+ 一時ストレージキュー、一時データキュー、ファイルアクセスなどの CICS サービスを再現するプラガブルクラスのセット (通常、Amazon Managed Service for Apache Flink、Amazon Simple Queue Service、または RabbitMQ for TD Queues などを複数実装することができます)。
+ ユーザー向けアプリケーションでは、BMS 画面記述形式が Angular ウェブアプリケーションにモダナイズされ、対応する「疑似会話」ダイアログがサポートされます。
+ 同様に、別のサブシステムには IMS メッセージベースのコレオグラフィが用意されており、MFS 形式の UI 画面のモダナイズをサポートします。
+ さらに、3 つ目のサブシステムを使用すると、DSPF (ファイル表示) 指定画面のモダナイズなどを含む、iSeries のような環境でプログラムを実行できます。
これらの環境はすべて、次のような一般的な OS レベルのサービスに基づいて構築されています。
+ 従来のメモリ割り当てとレイアウトのエミュレーション (**Data Simplifier**)、
+ COBOL 「実行ユニット」の実行とパラメータ受け渡しメカニズム (`CALL` ステートメント) の Java スレッドベースでの再現、
+ (**Blusam** ライブラリセットによる) フラット、連結、VSAM のエミュレーション、および GDG データセット組織、
+ RDBMS (`EXEC SQL` ステートメント) などのデータストアへのアクセス。
## ステートレス性とセッション処理
AWS Transform for mainframe Runtime の重要な機能は、モダナイズされたプログラムを実行するときに高可用性 (HA) と水平スケーラビリティのシナリオを有効にすることです。
その基礎となるのがステートレス性で、その重要な例は HTTP セッション処理です。
### セッション処理
tomcat はウェブベースであるため、このための重要なメカニズムは HTTP セッション処理 (tomcat と Spring が提供している) とステートレス設計です。こうしたステートレス設計は以下に基づいています。
+ ユーザーは HTTPS 経由で接続し、
+ アプリケーションサーバーはロードバランサーの背後にデプロイされ、
+ ユーザーがアプリケーションに初めて接続すると認証が行われ、アプリケーションサーバーは (通常は cookie 内で) 識別子を作成します。
+ この識別子は、ユーザーコンテキストを外部キャッシュに保存、および外部キャッシュから取得するためのキーとして使用されます (データストア)。
Cookie 管理は、メインフレームフレームワークの AWS 変換と基盤となる Tomcat サーバーによって自動的に行われます。これはユーザーにとって透過的です。ユーザーのインターネットブラウザがこれを自動的に管理します。
Gapwalk ウェブアプリケーションは、セッション状態 (コンテキスト) を以下のさまざまなデータストアに保存できます。
+ Amazon ElastiCache (Redis OSS)
+ Redis クラスター
+ メモリマップ内 (開発環境とスタンドアロン環境のみで、HA には適していません)。
## 高可用性とステートレス性
より一般的には、メインフレームフレームワークの AWS 変換の設計原則はステートレスです。レガシープログラムの動作を再現するために必要な非一時的な状態の大部分は、アプリケーションサーバー内に保存されませんが、外部で共通の「単一情報源」を通じて共有されます。
このような状態の例は、CICS の一時ストレージキューまたはリソース定義で、それらの一般的な外部ストレージは Redis 互換のサーバーやリレーショナルデータベースです。
この設計をロードバランサーおよび共有セッションと組み合わせると、ほとんどのユーザー向けダイアログ (OLTP、「オンライントランザクション処理」) を複数の「ノード」(ここでは tomcat インスタンス) に分散できるようになります。
実際、ユーザーはどのサーバーでもトランザクションを実行でき、次のトランザクションの呼び出しが別のサーバーで実行されても構いません。そうすれば、(自動スケーリングのため、または正常でないサーバーを置き換えるために) 新しいサーバーが作成されたときに、接続可能で正常なサーバーがトランザクションを期待どおりに実行し、適切な結果 (期待される戻り値、データベース内での予想されるデータ変更など) が得られるようになります。