多くのお客様は既に外部ワークロード・スケジューラーを使用して、z/OS でバッチ・ワークロードを管理しています。WebSphere Application Server 環境内で実行される Java バッチは魅力的ですが、WebSphere Compute Grid ジョブを外部ワークロード・スケジューラーから制御する方法は重要です。
Compute Grid は、WebSphere Extended Deployment バージョン 6.1 のコンポーネントであり、 完全なエンタープライズ Java バッチ・プログラミング・ソリューションを提供します。Computer Grid は、 簡潔で強力な Plain Old Java Object (POJO) ベースのプログラミング・モデル、 単純なパッケージ化とデプロイメント・モデル、フル機能のジョブ制御言語、 高度なジョブ・スケジューラー、堅固な実行環境、 および包括的なワークロード管理と管理ツールを備えています。これらの組み合わせによって、WebSphere Extended Deployment Compute Grid は、現在使用可能なもので最も完全な Java バッチ・ソリューションとなっています。
次の図で示すように、 バッチ・ジョブとは、ジョブ・マネージャーの制御下のバックグラウンドで実行される一連の プログラムのことです。各プログラムは、ゼロまたは 1 つ以上の入力データ・ソースを取り込み、ゼロまたは 1 つ以上の 出力データ・シンクを生成します。z/OS オペレーティング・システムは、成熟したバッチ・ジョブ処理環境の 例です。WebSphere Extended Deployment Compute Grid では、この処理モデルを一般化し、 WebSphere/Java 2 Enterprise Edition (J2EE) 環境で利用できるようにしています。
WebSphere Extended Deployment Compute Grid アプリケーションとは、 バッチ・インターフェースを実装し、WebSphere Extended Deployment バッチ・コンテナー によって呼び出される POJO クラスのことです。このアプリケーションは、 データ・ソースおよびシンクを表すバッチ・データ・ストリーム (BDS) を公開するコンテナー・サービスへのアクセス権を持っています。通常、 このようなアプリケーションの目的は、大量のレコード・セットに対して一括操作を実行することです。ジョブ定義には、 各ステップがバッチ POJO を呼び出す一連のステップを記述します。ジョブ定義には、ステップ実行の順序、 および各ステップで使用される入力/出力であるバッチ・データ・ストリームを記述します。
Compute Grid ジョブは、 次の図に示すように、WebSphere Application Server 内の バッチ・コンテナーと呼ばれる特殊なコンテナー内で実行されます。
ジョブ定義は、 特別な xJCL ファイルに記述される XML ベースのジョブ制御言語です。 xJCL ファイルは、WebSphere Extended Deployment ジョブ・スケジューラーに対して実行依頼されます。 スケジューラーは、その xJCL ファイルによって表されるジョブを、ターゲット・アプリケーションを構成する POJO をホストする WebSphere Application Server にディスパッチします。WebSphere Application Server 内で、バッチ・コンテナーは、非同期 Bean と呼ばれる 管理スレッドを作成し、ジョブを処理します。非同期 Bean は、 各ジョブ・ステップによって識別される POJO を呼び出し、 1 番目のステップから 2 番目のステップというように順に開始することによって、ジョブを処理します。各ステップによって呼び出される POJO は、ジョブ定義 (xJCL ファイル) によって記述された入力および出力バッチ・データ・ストリームへのアクセス権を持っています。
POJO は通常は、 多くの入力レコードを処理し、多くの出力レコードを生成します。POJO は、 WebSphere Application Server 内で実行されるため、J2EE プログラミング・モデルと、 トランザクションや接続管理などすべての WebSphere Application Server サービスの両方に対して、 全アクセス権限を持っています。POJO は効率を上げるために、他の Web および J2EE サービスをローカルで呼び出すことができます。
外部スケジューラーでは WebSphere Extended Deployment ジョブを直接管理する方法が識別されないため、 プロキシー・モデルが使用されます。プロキシー・モデルでは、通常の JCL ジョブを使用して、 WebSphere Extended Deployment ジョブの実行依頼またはモニター、あるいはその両方を行います。JCL ジョブ・ステップは、 WebSphere Extended Deployment によって提供される特殊プログラム WSGRID を呼び出します。 WSGRID アプリケーションは、指定された WebSphere Extended Deployment ジョブの実行依頼およびモニターを行います。WSGRID は、ジョブの中間結果を JCL ジョブの ジョブ・ログに書き込みます。WSGRID は、基本のジョブが完了するまで制御を返さないため、 同期実行モデルを提供しています。外部スケジューラーは、 JCL ジョブを管理できるため、WSGRID を呼び出す JCL ジョブを管理することができます。このパターンを使用して、 外部スケジューラーは、ジョブを間接的に管理することができます。ジョブ・スケジューラーのオプションの プラグイン・インターフェースを使用すると、外部スケジューラーの操作計画を更新して、 ジョブの開始、ステップの開始、ステップの終了、ジョブの終了など、 基本的なジョブの固有状態を反映させるコードを追加することができます。WSGRID プログラムは特別なリカバリー処理を備えているため、JCL ジョブが取り消されると、 基本のジョブも取り消されます。これにより、2 つのジョブのライフサイクルが同期化されます。
分散プラットフォームに対するジョブ制御も、次の図に示すように同様ですが、Job Entry Subsystem (JES) が分散プラットフォームでは不要になる点が異なっています。
多くのお客様は既に TWS を使用して、z/OS プラットフォームでバッチ・ワークロードを管理しています。WebSphere Application Server 環境内で実行される Java バッチは魅力的ですが、WebSphere Extended Deployment Compute Grid ジョブを TWS から制御する方法が必要になります。TWS では WebSphere Extended Deployment ジョブを直接管理する方法が識別されないため、 プロキシー・モデルが使用されます。プロキシー・モデルでは、通常の JCL ジョブを使用して、 WebSphere Extended Deployment ジョブの実行依頼およびモニターを行います。JCL ジョブ・ステップは、 WebSphere Extended Deployment によって提供される特殊プログラム (WSGRid ユーティリティーと呼ばれる) を呼び出します。 WSGrid コマンド行ユーティリティー を参照してください。
WSGrid アプリケーションは、指定された WebSphere Extended Deployment ジョブの実行依頼およびモニターを行います。WSGRid は、WebSphere Extended Deployment ジョブの中間結果を JCL ジョブの ジョブ・ログに書き込みます。WSGrid は、基本の WebSphere Extended Deployment ジョブが完了するまで制御を返さないため、 同期実行モデルを提供しています。TWS は、 JCL ジョブを管理できるため、WSGrid を呼び出す JCL ジョブを管理することができます。このパターンを使用して、TWS で間接的に WebSphere Extended Deployment ジョブを管理することができます。
WebSphere Extended Deployment ジョブ・スケジューラーのオプションの プラグイン・インターフェースを使用すると、TWS の操作計画を更新して、ジョブの開始、ステップの開始、ステップの終了、ジョブの終了など、 基本的な WebSphere Extended Deployment ジョブの固有状態を反映させるコードを追加することができます。WSGrid プログラムは特別なリカバリー処理を備えているため、JCL ジョブが取り消されると、 基本の WebSphere Extended Deployment ジョブも取り消されます。これにより、2 つのジョブのライフサイクルが同期化されます。