第4章 Interstage Business Application...

Copyright 2007 FUJITSU LIMITED 105

Copyright 2007 FUJITSU LIMITED

第４章Interstage Business Application

Server

本章ではInterstage Business Application Serverの機能について説明します。


Copyright 2007 FUJITSU LIMITED106

4.1 Interstage Business Application Serverの機能4.1 Interstage Business Application Serverの機能

Interstage Business Application Server

業務アプリA 業務アプリB

Java/C/C++/COBOL

Interstage Application Server Enterprise Edition

ルーティング制御ミッションクリティカル向け

制御ロジックジャーナルログ（高信頼性ログ）

メッセージ保証

24時間連続運転における安定稼動を保証する機構を

提供

アプリ不具合によるデータ矛盾の回避と復旧の機構を提供

ほかアプリケーション連携実行基盤

Interstage Business Application Severは、高い次元での安定性を必要とするミッションクリティカル

な業務を実行するアプリケーション実行基盤です。

Interstage Business Application Serverでは、オンライン業務を構築するための機能として、おもに

以下のような機能を提供しています。

■ミッションクリティカル向け制御ロジック

業務システムの安定稼動やデータ保全のロジックを、共通コンポーネントとして提供します。これにより、開発者は業務ロジックに専念できます。

■アプリケーション連携実行基盤

高い信頼性および高い品質が要求されるCOBOL、C言語およびJavaの制御ロジックを、アプリケー

ションの通信形態ごとに、「同期アプリケーション連携実行基盤」および「非同期アプリケーション連携実行基盤」として提供します。

■メッセージ保証機能

アプリケーション処理と業務データベースの一貫性を保証する機能です。アプリケーションが正常終了した場合には、メッセージや業務データはコミットされ、異常終了した場合には、ロールバックされます。

■ルーティング制御

複数のアプリケーションを組み合わせて業務を構築するための業務フロー定義にしたがって、メッセージをルーティングし、自動的にアプリケーションを呼び出す機能を提供します。複数アプリケーションからなる業務の開発を容易に行うことができます。

■ジャーナルログ (高信頼性ログ)課金や障害発生のデータ追跡などの目的のために、アプリケーションの処理状況(高信頼性ログ)を記録できるようなAPIを提供します。出力されたログデータは、各種のツールで分析などを行うことができ

ます。



4.1.1 ミッションクリティカル向け制御ロジック4.1.1 ミッションクリティカル向け制御ロジック

業務アプリケーション業務アプリケーション

業務ロジック業務ロジック

制御ロジック

InterstageBusiness Application

Server

共通コンポーネント

基幹システム構築の共通基盤

高信頼性機構

リトライ一貫性保証一意性保証異常時代行ルート管理例外／強制終了

非同期処理

キューの読み込みパラメタ解析振り分け処理キューデータ組み立てキュー書き込み

同期処理

リクエスト解析振り分け処理リクエストの返却

従来 InterstageBusiness

ApplicationServer

削減

Interstage Business Application Serverでは、ミッションクリティカル向けの制御ロジックを共通コンポーネントとして提供します。従来、業務システムの安定稼動やデータ保全は、アプリケーションの責任で行う必要がありましたが、これを共通コンポーネントとして提供することで、開発者は、業務ロジックに専念することができます。また、ソフト資産のミニマム化が促進され、スピーディに業務変更が行えます。

Interstage Business Application Serverが提供する高い信頼性および高い品質を実現する制御ロジックを、アプリケーションの通信形態ごとに、“同期アプリケーション連携実行基盤”および“非同期アプリケーション連携実行基盤”として提供し、これらの総称を“アプリケーション連携実行基盤”と呼びます。アプリケーション連携実行基盤のクライアントまたはサーバのアプリケーションで利用できる言語は、それぞれ以下のとおりです。

■同期アプリケーション連携実行基盤

・クライアントアプリケーションで利用できる言語－ Java (Servlet/EJB)

・サーバアプリケーションで利用できる言語－ C / COBOL (共有ライブラリ)

■非同期アプリケーション連携実行基盤

・クライアントアプリケーション(業務処理開始アプリケーション)で利用できる言語－ Java (Servlet/EJBまたはJavaアプリケーション)

・サーバアプリケーション(業務処理実行アプリケーション)で利用できる言語－ Java (クラス) / COBOL (共有ライブラリ)

共通コンポーネントには、メッセージ保証、ルーティング制御、ジャーナルログも含まれます。



4.1.2 アプリケーション連携実行基盤 (1/2)4.1.2 アプリケーション連携実行基盤 (1/2)

同期アプリケーション連携実行基盤

Webサーバ

WWWサーバ

アプリケーションサーバ


IJServerワークユニット

CORBAワークユニット

クライアントAPI

クライアントアプリケーション(Servlet/JSP)

同期アプリケーション連携実行基盤

クライアント

構成要素とデータの流れ

CO

RB

A

サービス

ログ定義

ファイル

データベースサーバ

アプリケーション実行制御

サーバアプリケーション

業務用データベース

・同期アプリケーション連携実行基盤で提供するオンライン処理(即時応答型)は、クライアントからの処理要求に対して、リアルタイムに処理結果を応答する処理形態

・処理の実行を要求するクライアントアプリケーションと要求された処理を実行する業務から構成

・クライアントアプリケーションとサーバアプリケーションは、同一のサーバ上で動作

Interstage Business Application Serverで運用する業務アプリケーションは、アプリケーション連携実行

基盤上で動作します。アプリケーション連携実行基盤には、同期アプリケーション連携実行基盤および非同期アプリケーション連携実行基盤の2つがあります。業務アプリケーションは、同期、非同期といった業務形

態に依存せず共通に開発できます。業務形態が変更になった場合もアプリケーションを変更することなく、アプリケーションの再利用が可能です。

同期アプリケーション連携実行基盤では、オンライン処理(即時応答型)におけるクライアントからの処理要

求に対して、リアルタイムに処理結果を応答する基幹系業務に必要な共通技術を提供します。

業務は、IJServerに配備するクライアントアプリケーションと、apfwdeploy配備コマンドを使用してCORBAワークユニットに配備するサーバアプリケーションを使用して構築します。

■クライアントアプリケーション同期アプリケーション連携実行基盤のクライアントAPIを実行してサーバアプリケーションにリクエストを発行するServlet/EJBアプリケーションです。(Java単体のアプリケーションとしても実装可能ですが推奨しません。)

■サーバアプリケーションクライアントアプリケーションの入力情報に応じて業務用のデータベースの更新などの業務処理をするアプリケーションです。COBOLまたはC言語の共有ライブラリとして作成します。

同期アプリケーション連携実行基盤では、要求応答型のアプリケーション連携を行うことができます。クライアントアプリケーションがサーバアプリケーションに要求を発行し、サーバアプリケーションでは、処理結果をクライアントアプリケーションに応答します。

このとき、クライアントアプリケーションは、サーバアプリケーションの処理が完了するまで応答を待ち合わせます。

同期アプリケーション連携実行基盤がサーバアプリケーションの実行を制御します。実行制御機能として、以下を提供します。


■動作モードサーバアプリケーションの動作モードとしてスレッドモードとプロセスモードを提供します。アプリケーションの多重度は、スレッド単位(1プロセスnスレッド)、プロセス単位(nプロセス)および混在(mプロセスnスレッド)で設定できます。

■トランザクションとリトライ制御データベース操作を伴う処理では、処理結果により、トランザクションの完了操作を行う必要があります。また、エラー終了した場合には、業務処理の再実行が必要な場合があります。同期アプリケーション連携実行基盤では、これらの操作をアプリケーションの処理結果情報に2(異常終了)または3(強制リトライ)が設

定されていた場合にリトライの定義にしたがってリトライ処理します。リトライ実行時のリクエストデータは初回呼び出し時のデータが渡されます。

■プレロード・ダイナミックロードアプリケーションのライブラリをロードするタイミングをプレロードとダイナミックロードの2種類から選択でき

ます。

・プレロード同期アプリケーション連携実行基盤のプロセス起動時にユーザ作成ライブラリをロードします。性能向上のためアプリケーションをプロセス起動時にメモリに常駐する場合に使用し、アプリケーションのアクセスを初回から高速化できます。

・ダイナミックロードユーザ作成ライブラリをリクエスト時に動的にロードを行い、リクエスト終了後にアンロードします。つねに動作する必要がないユーザ作成ライブラリやユーザ作成ライブラリの常駐メモリを節約する場合などに用います。

■COBOL実行環境の開設・閉鎖COBOL実行環境のWORKING-STORAGE SECTION における無駄な領域の獲得や解放をしない制御が可能です。COBOL実行環境の開設から閉鎖までの間、変数などの実行環境情報がCOBOLランタイムで保持される(前回呼び出し時の状態が保持される)ため、アプリケーションで共通に使用する情報を保

持しておくことができます。

■データ型変換サーバアプリケーションの言語に合わせて、データ型の変換を処理します。

■ログ出力同期アプリケーション連携実行基盤の稼動状況および性能情報の2種類のログを自動的に出力する標準

ログ機能を提供します。



4.1.2 アプリケーション連携実行基盤 (2/2)4.1.2 アプリケーション連携実行基盤 (2/2)

非同期アプリケーション連携実行基盤

Webサーバ

WWWサーバ



非同期基盤

ワークユニット

データベースサーバ

メッセージトラッキング

DB

フロー定義DB


メッセージ格納DB

ワークユニットワークユニット

アプリケーション連携実行基盤

API

業務処理開始アプリケーション


(実行環境)

業務処理実行アプリケーション


(実行環境)

業務処理実行アプリケーション

キューキューキュー

データベースアクセス(追加/更新/削除)

クライアント

Servlet/JSP

・業務用データベース利用者の業務で使用するデータを格納するデータベース

・フロー定義DBアプリケーション連携を指定したフロー定義を格納するデータベース

・メッセージトラッキングDBアプリケーション連携の処理中に発生したエラー情報を格納するデータベース

・メッセージ格納DBメッセージとDBの整合性保証機能を使用する場合にアプリケーションで使用するメッセージを格納するデータベース

・非同期基盤Interstage Application ServerのイベントサービスおよびJMS機能

構成要素とデータの流れ

非同期アプリケーション連携実行基盤は、フロー定義にしたがってCOBOLおよびJavaアプリケーションの呼び出しを行う実行環境です。

非同期アプリケーション連携実行基盤では、非同期型のオンライン処理(突き放し型など)および複数業務を相互接続する業務モデル(HUB型)において、フロー定義にしたがってCOBOLまたはJavaのアプリケーションを連携し、処理結果を応答する基幹系業務に必要な共通技術を提供します。

業務は、業務処理開始アプリケーションおよび業務処理実行アプリケーションを使用して構築します。

■業務処理開始アプリケーション非同期アプリケーション連携実行基盤のフロー起動APIまたは結果受信APIを実行して業務処理実行アプリケーションを連携した業務(フロー)の開始、および業務(フロー)の処理結果を受信するServlet/EJBアプリケーションです。IJServerに配備して運用します。(Java単体のアプリケーションとしても実装可能ですが推奨しません。)

■業務処理実行アプリケーションメッセージの内容に応じて業務用のデータベースの更新などをする業務処理アプリケーションです。COBOLでアプリケーションを作成する場合、同期アプリケーション連携実行基盤のサーバアプリケーションと同一の方法でアプリケーションを作成します。業務処理実行アプリケーションをCOBOLで作成する場合は、apfwdeploy配備コマンドを使用して非同期ワークユニットに配備し、Java(Message-driven Bean)で作成する場合は、IJServerに配備して運用します。

また、非同期アプリケーション連携実行基盤では、エラーメッセージを処理するアプリケーション(エラーメッセージ処理アプリケーション)を使用できます。

■エラーメッセージ処理アプリケーション業務処理実行アプリケーションで異常が発生した後、エラーメッセージ退避キューに格納されたメッセージをエラーメッセージ取得APIを実行することで受信し、エラー内容を業務ログに出力するなどの異常時運用をするアプリケーションです。アプリケーションは、Java単体のアプリケーションとして作成し、ユーティリティワークユニットに配備して実行します。エラーメッセージ処理アプリケーションは、クライアントからのリクエストにより開始されるのではなく、エラーメッセージ退避キューにメッセージが格納されたのを契機に開始されます。

非同期アプリケーション連携実行基盤が、業務処理実行アプリケーションの実行を制御します。実行制御機能として、以下を提供します。


【COBOLで作成した業務処理実行アプリケーションの場合】

■動作モード業務処理実行アプリケーションの動作モードとしてスレッドモードとプロセスモードを提供します。アプリケーションの多重度は、スレッド単位(1プロセスnスレッド)、プロセス単位(nプロセス)および混在(mプロセスnスレッド)で設定できます。

■トランザクションとリトライ制御データベース操作を伴う処理では、処理結果により、トランザクションの完了操作を行う必要があります。また、エラー終了した場合には、業務処理の再実行が必要な場合があります。非同期アプリケーション連携実行基盤では、これらの操作をアプリケーションの処理結果情報に2(異常終了) が設定されていた場合にフロー定義にしたがってリトライ処理します。リトライ実行時のリクエストデータは初回呼び出し時のデータが渡されます。

■プレロード・ダイナミックロードアプリケーションのライブラリをロードするタイミングをプレロードとダイナミックロードの2種類から選択できます。

・プレロード非同期アプリケーション連携実行基盤のプロセス起動時にユーザ作成ライブラリをロードします。性能向上のためアプリケーションをプロセス起動時にメモリに常駐する場合に使用し、アプリケーションのアクセスを初回から高速化できます。

・ダイナミックロードユーザ作成ライブラリをリクエスト時に動的にロードを行い、リクエスト終了後にアンロードします。つねに動作する必要がないユーザ作成ライブラリやユーザ作成ライブラリの常駐メモリを節約する場合などに用います。

■COBOL実行環境の開設・閉鎖COBOL実行環境のWORKING-STRAGE SECTION における無駄な領域の獲得や解放をしない制御ができます。COBOL実行環境の開設から閉鎖までの間、変数などの実行環境情報がCOBOLランタイムで保持される(前回呼び出し時の状態が保持される)ため、アプリケーションで共通に使用する情報を保持しておくことができます。

■データ型変換サーバアプリケーションの言語に合わせて、データ型の変換を処理します。

■ログ出力非同期アプリケーション連携実行基盤の稼動状況および性能情報の2種類のログを自動的に出力する標準ログ機能を提供します。

■異常処理アプリケーションの処理結果とフロー定義の内容に応じてアプリケーションで異常が発生した場合、受信したメッセージを“エラーメッセージ退避キューに退避”、“シリアライズファイルへ出力”または“補償ルート”のいずれかにより異常処理することができます。

【Javaで作成した業務処理実行アプリケーションの場合】

■動作モード業務処理実行アプリケーションの動作モードとしてスレッドモードを提供します。アプリケーションの多重度は、スレッド単位(1プロセスnスレッド)で設定できます。

■トランザクションとリトライ制御データベース操作を伴う処理では、処理結果により、トランザクションの完了操作を行う必要があります。また、エラー終了した場合には、業務処理の再実行が必要な場合があります。非同期アプリケーション連携実行基盤では、これらの操作をアプリケーションの処理結果情報に2(異常終了) が設定されていた場合にフロー定義にしたがってリトライ処理をします。リトライ実行時のリクエストデータは初回呼び出し時のデータが渡されます。

■ログ出力非同期アプリケーション連携実行基盤の稼動状況および性能情報の2種類のログを自動的に出力する標準ログ機能を提供します。

■異常処理アプリケーションの処理結果とフロー定義の内容に応じてアプリケーションで異常が発生した場合、受信したメッセージを“エラーメッセージ退避キューに退避”、“シリアライズファイルへ出力”または“補償ルート”のいずれかにより異常処理することができます。




業務処理アプリケーション

4.1.3 メッセージ保証機能4.1.3 メッセージ保証機能

メッセージ保証機能

アプリケーション連携実行基盤（実行環境）

異常終了

要求元アプリケーションメッセージメッセージが消失

してしまい処理の継続不可

要求元アプリケーションメッセージメッセージ

メッセージ

メッセージ


業務処理アプリケーション

処理要求メッセージ格納キュー


呼び出し

アプリケーション連携実行基盤では、アプリケーションの連携を行う手段としてメッセージを使用します。メッセージ保証機能では、アプリケーション連携に使用するメッセージの送受信と業務処理で使用する業務用データベースの更新を一意な処理単位として、システムダウンやアプリケーション異常が発生しても、一貫性を保証する機能を提供します。なお、システムダウンなどの異常発生時にもメッセージを消失することなく一貫性を保証するため、メッセージの格納先は、メッセージ格納DBを使用します。

■メッセージ保証機能とトランザクションメッセージ保証機能は、メッセージおよび業務用データベースの一貫性をデータベースのローカルトランザクションにより保証します。業務処理実行アプリケーションの言語により以下の設定が必要です。

・COBOLの業務処理実行アプリケーションメッセージ保証機能を使用する場合、データベースアクセス管理機能を使用する必要があります。アプリケーションが、業務用データベースをアクセスするデータベースリソース定義をメッセージ格納DBのデータベースリソース定義として使用します。このように、COBOLアプリケ－ションでは、データベースアクセス管理機能を使用することで、同一のトランザクションでメッセージと業務用データベースを同期できます。データベースアクセス管理機能は、開発者がデータベースアクセスのためのコネクション制御およびトランザクション制御を意識することなく、業務ロジックに専念して開発する仕組みを提供する機能です。

・Javaの業務処理実行アプリケーションアプリケーション連携実行基盤の実行環境のベースとなるEJB(Message-driven Bean)では、トランザクション管理種別はCMT(Container-Managed Transaction)、トランザクション属性はRequiredを設定する必要があります。EJB(Message-driven Bean)より呼び出す業務処理実行アプリケーションから、EJBアプリケーションを呼び出す場合のトランザクション管理種別はCMT(Container-Managed Transaction) 、およびトランザクション属性は、Mandatoryを設定する必要があります。

なお、メッセージ保証機能では、メッセージの順序性は保証されません。データベースの更新順番を厳守するなどの理由により、メッセージの順序性保証が必要な業務に適用する場合は、アプリケーションや運用により順序性を保証する必要があります。



4.1.4 ルーティング制御4.1.4 ルーティング制御

ルーティング制御

ルーティング制御

・ルーティング定義/呼び出し定義を獲得

・送信先の決定・メッセージの組み立て

・アプリケーションへ入力情報の引き渡し、および出力情報の受け取り

・送信先の決定・メッセージ送信

API

API

メッセージ送信

入力情報

出力情報

ジョブフロー定義

次の送信先へ

アプリケーション


アプリケーションからルーティング制御の

APIを利用

アプリケーションは、ルーティングを意識せず

メッセージの出し入れだけ

フロー定義DB

ルーティング定義情報呼び出し定義情報フローの制御情報業務データ



ルーティング制御機能は、フロー定義にしたがってメッセージをルーティングし、アプリケーションを自動的に呼び出す機能です。

従来、アプリケーションの制御ロジックで行っていたアプリケーションの呼び出しやメッセージのルーティング先を判断し、送信する処理をルーティング制御機能が代替して実行します。これにより、アプリケーションを連携するシステム構築を早期に実現することが可能となります。

ルーティング情報は、フロー定義ツールで行いフロー定義DBへ格納されます。メッセージを発行する業務アプリケーションでは、アプリケーション連携実行基盤が提供するルーティング制御用APIにフロー定義名および業務データの内容などを指定して、メッセージを発行します。そのため、既存アプリケーションをメッセージを発行するアプリケーションとする場合、アプリケーション内にルーティング制御用APIを組み込む必要があります。

ルーティング制御機能では、フロー定義DBに格納されたフロー定義および運用情報の更新確認を行い、ルーティング定義および呼び出し定義を獲得します。

ルーティング制御機能では、獲得したルーティング情報をもとに初に送信するキューを決定し、送信します。ルーティング制御機能では、受信したメッセージから呼び出し定義情報を獲得し、ユーザアプリケーションに業務データを受け渡しします。

ルーティング定義では、アプリケーション連携を行うために以下の情報を設定します。

■業務全体の流れ

■アプリケーションの入力メッセージを一時的に蓄積するキュー名

■フロー分岐(条件式)

■メッセージの1:n(複数)送信

■エラーが発生したときにメッセージを退避するエラーメッセージ退避キュー

■メッセージを振り分けるための代行ルート


処理の分岐(フローの分岐)が必要な場合は、ルーティング定義のフロー分岐で分岐条件が指定できるため、アプリケーションで分岐先などの指定を行う必要がありません。

ルーティング制御機能では、メッセージから獲得したルーティング情報をもとに次に送信するキューを決定します。送信先が分岐されている場合は、フロー定義で指定された分岐するための条件式でメッセージに格納されている業務データを評価し真となる送信先へメッセージを分岐します。

1つのメッセージを複数のアプリケーションへ送信することも可能です。



4.1.5 高信頼性ログ（ジャーナルログ）4.1.5 高信頼性ログ（ジャーナルログ）

アプリケーション処理

SQL処理

ログ出力

コミット/ロールバック

業務データベース

ユーザログ(SQL処理結果)

トランザクション処理結果

確実なログ取得のための格納構造

■高速挿入、循環使用に特化した格納構造■容量満杯や障害発生の場合はエントリを自動切り替え■エントリごとにI/O分散・危険分散が可能■Symfowareで高信頼性ログを構築することも可能

高信頼性ログ機能ログ出力

ログ出力

ログ確定

自動確定

バックアップやバッチ業務などへの利用を目的とした高信頼性ログ（ジャーナルログ）機能を提供します。

高信頼性ログは、データベースのトランザクションと同期して採取され、データベースと一致します。

業務処理の結果だけを記録するデータベースとは別に、業務処理の履歴が確実に記録されます。これにより、データベース破損時の復元に利用できます。

高信頼性ログ機能には、以下の特長があります。

■エンドレスなファイル管理

サイクリックな格納構造によって、エンドレスにファイル管理ができます。この格納構造には、以下の特長があります。

・高速挿入、循環使用に特化した格納構造

・容量満杯や障害発生の場合はエントリを自動切り替え

・エントリごとにI/O分散・危険分散が可能

■ユーザログのトランザクションの一貫性の保証

高信頼性ログ機能は、以下の機能によって、トランザクションに一貫性のあるログ取得を実現します。

■データベースと同等の堅牢な書き込み保証

高信頼性ログの書き込みは、Symfowareをベースにしており、データベースで培われた高い信頼性を実現しています。以下の場合も、トランザクションの完了またはログの書き込み確定が行われたユーザログの書き込みは保証されます。

・システムダウン、コネクション切断時は、テンポラリログから自動リカバリ

・メディア障害時は、アーカイブログから rdbrcv コマンドによってリカバリ


■ユーザログの書き込み順番の保証

ユーザログテーブルの論理定義で格納順番号を指定することによって、格納順番号をユーザログレコードに自動付加します。これをもとにソート処理を行うことで、書き込み順にログを参照することが可能となります。

■パーティショニングによるデータアクセスの高速化

ユーザログテーブルは、格納構造定義により、規則に基づいてDSIを複数に分割することで、それぞれを独立させて運用できます。これを、パーティショニングといいます。パーティショニングを行うことで、ユーザログテーブルを分割した単位で独立かつ並行して運用することができるため、運用単位を小さく、かつ並行に処理できます。細分化されたユーザログテーブルは内部的に独立して処理されるため、複数のトランザクションの同時実行性が高まり、ディスク入出力が分散されます。これにより、データアクセスの高速化を実現できます。



第５章Interstage Job Workload Server

本章ではInterstage Job Workload Serverの機能について説明します。



5.1 Interstage Job Workload Serverの機能5.1 Interstage Job Workload Serverの機能

オンライン業務バッチ業務


Interstage Job Workload Server

バッチ実行基盤

バッチ実行機能

運用ユーティリティ(ジョブ操作/システム保守/セットアップ)バッチ受付機能

ファイル管理

バッチアプリケーション

（COBOL）

NetCOBOL開発/運用機能

バッチ処理の安定稼動を

実現


Interstage Job Workload Serverが提供するバッチ実行基盤の特徴は、以下のとおりです。

■業務アプリケーションの生産性向上

・既存のアプリケーションの実行

開発済みのアプリケーション（コマンドやシェルスクリプト）をバッチ実行基盤で実行できます。

・業務の簡単な構築

業務フロー（バッチジョブ定義）のGUI定義ツール（バッチジョブ定義エディタ）を提供します。バッチジョブ定義エディタでは、アプリケーションの呼び出し順序、アプリケーションで使用するファイルなどの資源の事前排他獲得、アプリケーション間で受け渡すファイルなどの資源、アプリケーションで異常が発生した場合の実行順番などを定義できます。

また、ジョブを実行するときにバッチジョブ定義の定義情報（置き換えパラメタ）を変更できるため、ジョブの可用性が向上します。

・ファイル制御の意識が不要

バッチジョブ定義に指定した異常処理定義により、アプリケーションでエラーが発生したときの獲得済みファイルの削除／排他解放などを実現します。このため、バッチ実行基盤で使用するアプリケーションが異常終了した場合のファイルなどの資源回収が簡単になり、アプリケーションの開発が業務処理ロジックに専念できます。

・プログラムの可用性の向上

アプリケーションのプログラム中にハードコーディングされるファイル名の情報を抽象化できます。実行時に抽象化したファイル名と実ファイル名を対応づけ、抽象化したファイルを取り扱います。このため、プログラムの可用性が向上します。


■業務の安定性向上

・資源の破壊防止

バッチジョブ定義に指定した資源は、ジョブ開始時に排他の獲得ができます。このため、複数のジョブによる資源の競合を防ぐことができ、資源の破壊を防止します。

■システムの運用性向上

・異常終了したジョブステップからリスタート

ジョブの実行時にファイルなどの資源の割り当て／解放状況を実行結果として記録します。ジョブが異常終了した場合、実行結果を参考にして、異常終了したジョブステップ（アプリケーション）から再実行できます。

■システム運用の改善

ジョブの実行時間を記録できます。ジョブの実行時間の記録をもとに、処理時間が長いジョブを特定し、システム運用を改善できます。



5.1.1 ファイル資源の一括排他機能5.1.1 ファイル資源の一括排他機能

JOB1

JOB2

ファイル定義

ファイル定義排他制御

排他制御

排他待ち

定義情報にしたがって効率的な排他制御

を実施

ファイル管理機能がAPL1とAPL2のため連続して

ファイルを排他制御ファイルBはAPL1の

間だけ排他制御

アプリケーションで排他のロジックは不要

APL1

APL2

・ファイルA・ファイルB

・ファイルA APL・ファイルA

ファイルA

ファイルB

Interstage Job Workload Serverでは、バッチジョブで発生するファイルの排他を、複数のジョブで効率的に制御します。

排他制御の対象となるファイルは、バッチジョブ定義エディタにより定義します。複数のジョブが、同じファイルを更新する場合に発生するファイルの破壊を防止するため、ファイルの排

他機能は、バッチジョブ定義の指定にもとづいて、ジョブ単位にファイルの排他を獲得します。また、ジョブステップ終了時またはジョブ終了時に、ジョブが使用したファイルの排他を解除します。このため、アプリケーションや運用で排他機構を用意する必要がなくなります。

ファイルを更新するジョブを実行する場合は、そのジョブが終了するまで、ほかのジョブがファイルの参照、および更新できないようにする必要があります。また、複数のジョブがファイルの参照だけを行う場合は、それらのジョブの間で、同一のファイルを同時に使用できる必要があります。

ファイルの排他機能は、これらの要件を満たすため、以下の種類があります。

■排他モードほかのジョブからのファイルの使用を抑止します。

■共用モード複数のジョブで同時に同じファイルを参照することを許可するか、抑止するかの選択が可能です。共用モードを指定した複数のジョブで同じファイルを参照できます。

また、ファイルが先行ジョブですでに使用されている場合、後続ジョブの動作を指定できます。先行ジョブがファイルを使用していた場合、排他が獲得できるまで待つか、エラーで終了するかの選択が可能です。

■待ち指定ファイルの排他が獲得できるまで当該ジョブの実行を待ち合わせます。

■エラー指定ジョブがエラー終了します。

これらの制御を受けるためには、バッチジョブ定義のジョブステップ定義の資源に設定しファイル管理機能により制御される必要があります。このため、ジョブステップの資源に登録しないファイルや、ファイル管理機能外の一般のファイル操作コマンドによる操作では、これらの排他制御を受けることができません。



ジョブ起動時に世代ファイルの割り当てが可能

起動ごとにファイル名を変更するため、定義ファイルを変更せずに毎時動作するバッチ運用が可能

5.1.2 ファイルの世代管理5.1.2 ファイルの世代管理

file1.G0002業務処理

２回目２回目

プログラム１

file1

プログラム1ディレクトリ名：dir001世代ファイル名：file1新規大世代：3・・・

file1.G0001

ファイル名を変更しなくても、ジョブ起動ごとに自動採番してファイルを世代管理する

大世代を超えると初のファイルに

戻り上書き

自動採番

JOB定義JOB定義

業務処理

１回目１回目

プログラム１

更新業務処理

１回目１回目

プログラム１file1 バック

アップ

更新業務処理

２回目２回目

プログラム１file1 バック

アップ

ファイル名が毎回同じであるため、起動ごとに退避処理が必要

【従来のファイル管理】【ファイル世代管理】

自動採番

ファイルの世代管理機能は、ジョブ起動時に世代ファイルの割り当てを可能とする仕組みです。バッチアプリケーションが実行時に作成するファイル資源のバックアップを保存し、ファイルの世代を管理

します。

世代管理機能がない場合、ファイル名を変更しない限り、バッチアプリケーションが作成するファイルは新情報で上書きされてしまいます。

バッチ業務処理において、途中のジョブが異常終了した場合や、バッチ業務間でファイルを引き継ぐバッチ処理において後続のバッチ業務処理でデータをロストした場合などに、処理が完了済みのジョブを実行しなおすことなく、保存されている世代ファイルを使用して業務を継続することができます。

ジョブで使用する世代ファイルは、バッチジョブ定義の資源定義から指定します。バッチアプリケーションに対するファイル名の受け渡しには、通常どおり環境変数でファイル情報を通知す

るため、バッチアプリケーションは各世代のファイルを意識することなく、資源名を指定して世代ファイルへアクセスすることができます。

■世代ファイルの管理方法

世代ファイル名とは、ファイルの世代管理機能を使用する場合に使用する仮想的なファイル名であり、物理的なファイル名ではありません。ファイルの世代管理機能は、新規に作成するファイルに対して世代ファイル内で一意の番号(絶対世代番号)を割り振って各世代のファイルを管理します。絶対世代番号は、0～9999の値です。各世代のファイル名は、世代ファイル名の末尾にピリオドで‘G’＋絶対世代番号を付加し

て識別します。

世代ファイル名が「fileA」、絶対世代番号が1の場合、実際のファイル名は「fileA.G0001」になります。

絶対世代番号が9999を超えた場合は、0に戻ります。この場合、同一の絶対世代番号を持つ世代ファイル

および世代情報が存在した場合は、その世代ファイルおよび世代情報を消去してから作成します。

■世代ファイルのファイル排他

世代ファイルを使用する場合、各世代のファイル単位(実ファイル名)ではなく、世代ファイル単位(ディレクトリ名＋世代ファイル名)に対してファイルを排他します。排他の獲得・解除契機は、世代ファイル以外の他のファイル(非世代ファイル)と同じ契機です。排他の解除はジョブが使用する世代ファイルのバッチジョブ定義の[資源の後処理]の指定に基づきます。



ジョブ実行制御



5.1.3 ジョブ異常時のリカバリ機能5.1.3 ジョブ異常時のリカバリ機能

異常

正常終了リスタート

ジョブの実行結果を記録

異常終了による不要ファイル自動的に

ファイルを回収

異常終了したアプリケーションから

リスタート

Interstage Job Workload Serverでは、ジョブ異常時の迅速な対処を以下のような機能により自動化することでシステムの運用性を向上します。また、開発者の異常時処理の考慮についての負担を軽減できます。ジョブで実行するアプリケーションにおいて異常終了時の処理を記述する必要はありません。

■ファイル資源回収の自動化ジョブが異常終了した場合に、ジョブにより発生した不要な中間ファイルを自動的に回収するために、未回収ファイルを検索して削除する作業が不要になります。

■ジョブ異常時のリスタートジョブの実行時にファイル資源の割り当て、回収状況を実行結果として記録しているため、ジョブが異常終了した場合、初からジョブをリスタートするのではなく、異常終了したアプリケーションからリスタートできます。



5.1.4 ジョブの開発支援機能5.1.4 ジョブの開発支援機能

バッチジョブ定義エディタ：Interstage Studio

ジョブ定義の設定

基本情報設定環境変数定義ステップ定義終了条件定義

ジョブステップ定義の設定

基本情報設定実行条件定義バッチアプリケーション定義資源定義資源定義の設定

資源設定

バッチジョブ定義データベース

ウィザードによるジョブ定義

Interstage Studioの

プラグインとして動作

Interstage Job Workload Serverのバッチ実行基盤で業務を運用するには、以下を開発する必要があります。

■バッチアプリケーション

■バッチジョブ定義

バッチアプリケーションは、COBOLアプリケーション／コマンド／シェルスクリプトで作成することができます。COBOLアプリケーションはNetCOBOLで開発し、コマンド／シェルスクリプトは、各種開発言語で

開発します。また、作成したバッチアプリケーションは、実行環境としてバッチワークユニットを使用します。

動作環境の定義であるバッチジョブ定義は、Interstage Studioで動作するバッチジョブ定義エディ

タを使用して作成します。作成されたバッチジョブ定義情報は、バッチサーバに転送したあと、バッチサーバ上でコマンドを使用して、バッチジョブ定義データベースへの登録します。

Interstage Studioによるバッチジョブ定義の作成の流れを以下に示します。

1.Interstage Studioの起動

2.バッチジョブ定義プロジェクトの作成

3.ジョブ定義ファイルの作成

4.バッチジョブ定義ファイルの操作

5.ジョブ定義の設定

6.ジョブステップ定義の設定


MEMO



第６章Interstage Studioでのアプリケーション開発

本章ではInterstage Studioを使用して、Interstage Application Serverで動作するアプリケーションの開発を行う場合

に必要となる基本的な手順について説明します。



6.1 Interstage Studioとは6.1 Interstage Studioとは

Interstage Studio

Java統合開発環境

画面フォームデザイナ

ソースコードエディタ

電子フォームデザイナ

ソースコードデバッガ

運用テスト環境アプリケーションサーバ

画面フォームデザイナ

UMLモデリングツール

各種ウィザード

各種部品

ひな型ソース生成

ビットマップ

Servlet

JSP

EJB(EJB2.0対応）

CORBA/OLTPアプリケーション

Webアプリケーション

クライアントアプリケーション

電子フォームアプリケーション

スキャナ

ActiveXJavaBeans

Applet

Interstage Studioは、従来のWebアプリケーション開発から新のWebサービス開発までの幅広いアプリケーション開発に対応した、コンポーネント指向のJava統合開発環境です。

Interstage Studioでは、オープンソースのeclipseプロジェクトで開発されたeclipse3.2プラットフォームをベースにした統合開発環境として、ワークベンチを提供しています。ワークベンチには、アプリケーションを効率良く行うための各種デザインツール、開発支援ツール、豊富なコンポーネント部品が組み込まれています。

ワークベンチを使用することで、以下のアプリケーションを開発できます。

■Javaアプリケーション各種プラットフォームで動作可能なJava言語記述によるクライアントアプリケーション、Applet、JavaBeansを開発できます。

■WebアプリケーションWebサーバ上で動作するServlet、またはJavaServer Pages(JSP)を使用するWebアプリケーションを開発できます。

■Enterprise JavaBeans分散オブジェクトアーキテクチャであるEnterprise JavaBeans (EJB)にもとづいた、Enterprise Bean(EB)を開発できます。

■エンタープライズアプリケーションEJBやWebアプリケーション、J2EEアプリケーションクライアントを組み合わせて多階層アプリケーションを開発できます。

■WebサービスアプリケーションInterstage上で動作するサーバサイドのWebサービスアプリケーション、およびリクエストを送信するWebサービスクライアントアプリケーションを開発できます。

■ApcoordinatorアプリケーションJ2EEに従ったアプリケーションの構築を支援するフレームワークを用いて、Webアプリケーション、電子フォームアプリケーション、EJBを開発できます。

■CORBAアプリケーションInterstage Application Serverが提供するCORBAサービスを利用したCORBAアプリケーションを開発できます。



6.2 アプリケーションの開発手順6.2 アプリケーションの開発手順

ワークベンチでのアプリケーション開発手順

プロジェクトの作成プログラムの記述ビルド配備

■Webアプリケーションの開発手順

デバッグ

■ワークベンチでの基本的なアプリケーション開発の流れ

Webアプリケーションプロジェクトを定義

Webライブラリを定義

Webリソースの編集/処理手続きの記述

プロジェクトのビルド

Webサーバに配備

Webリソース/クラスを作成

プロジェクトをデバッグ

※：必要に応じてデバッグを行い、デバッグ後は、再度「プロジェクトのビルド」、「Webサーバに配備」を実行する

(※)

ワークベンチでは、プロジェクト単位でソースプログラムやライブラリなどアプリケーションを作成するために必要なファイルを管理します。よって、サーバアプリケーションを開発するときは、まず、作成するアプリケーションのプロジェクトを作成し、プロジェクト内でソースプログラムの記述、ライブラリの配置などを行い、プロジェクトのビルド、アプリケーションサーバへ作成したサーバアプリケーションを配備する、という手順が基本になります。

例えば、Webアプリケーションは、以下の手順で開発します。

■Webアプリケーション

1. Webアプリケーションプロジェクトを作成する

2. Webライブラリを定義する

Webアプリケーションから使用するJAR形式のクラスライブラリがある場合、WEB-INF/lib配下にJARファイルを格納して利用します。

3. Webリソース(静的コンテンツやWebコンポーネント)および必要なクラス(Servlet)を作成する

Webアプリケーションで利用する静的Webリソース(HTML/JavaScript/CSS など)および動的コンテンツを生成するJSP/Servletを作成します。HTML/JavaScript/CSS/JSP/Servlet は、ワークベンチが提供するウィザードを利用して生成でき

ます。

4. Webリソースの編集およびServletのJavaアプリケーション処理手続きを記述する

5. Webアプリケーション環境定義ファイルを定義する

Webアプリケーションのdeployment descriptor(web.xml)でWebアプリケーションの環境定義を

記述します。

6. Webアプリケーションプロジェクトをビルドする

Webアプリケーションは、WARファイルにアーカイブして配備します。ワークベンチの初期状態では、ファイルの保存時に自動的にビルドが行われるように設定されています。Webアプリケーションプロジェクトではビルド時にWARファイルを作成するようにビルダが設定されています。


7. Webサーバ(運用サーバ)に配備する

8. Webアプリケーションプロジェクトをデバッグする

「8. Webアプリケーションプロジェクトをデバッグする」は、デバッグが必要な場合に行い、デバッグ後は、再度「6. Webアプリケーションプロジェクトをビルドする」、「7. Webサーバに配備する」を実行します。



6.3 ワークベンチの画面6.3 ワークベンチの画面

プロジェクトエクスプローラビュー

エディタ

IJServer ビュー

タグパレットビュー

問題/Javadoc/宣言/コンソール/プロパティの各ビューを切り替え

アウトラインビュー

【J2EEパースペクティブ】

ワークベンチの開発画面は、各種のビューとエディタを組み合わせたパースペクティブで構成されています。J2EEアプリケーションを作成する際は、EJBやWebアプリケーションの開発のために用意された「J2EEパースペクティブ」が自動的に起動され、開発を効率的に行うことができます。

「J2EEパースペクティブ」以外にも、Apcoordinatorアプリケーションを開発するための「Apcoordinatorパースペクティブ」、プログラムをデバッグするための「デバッグパースペクティブ」などが用意されています。

J2EEパースペクティブは、おもに以下のビューとエディタを組み合わせて画面を構成しています。

■プロジェクトエクスプローラビュー

ワークベンチ内のプロジェクトのJavaエレメント階層を表示します。J2EEのdeployment descriptorの内容が表示され、定義内容の概要を参照することができます。

■アウトラインビュー

エディタ領域で開いている構造化されたファイルの概略、および要素の一覧が表示されます。

■タグパレットビュー

HTML、JSP標準アクション、JSPディレクティブおよびJSP拡張タグなどのタグをカテゴリにわけて表示します。画面モードまたはテキストモードで、タグパレットビューの各カテゴリに表示される要素をドラッグ＆ドロップをするか、ダブルクリックすることにより、選択したタグを挿入することができます。

■IJServer ビュー

ローカル、またはリモートにあるInterstage Application Serverとその資産を表示し、これらの機能を操作できます。

■問題ビュー

ワークベンチ内のリソースの作業を行う際にビルダが発生する問題、エラー、または警告を自動的に記録します。

■Javadoc ビュー

Java エディタで選択されたエレメントの Javadoc を表示します。

■宣言ビュー

Java エディタで選択されたエレメントのソースを表示します。


■コンソールビュー

プログラム実行の出力が表示され、さらにプログラムへ入力することもできます。コンソールは、異なる3種類のテキスト(標準出力、標準エラー、標準入力)を、それぞれ色を変えて表示します。

■プロパティビュー

リソースなど、選択された項目のプロパティの名前および値を表示します。

■エディタ

Javaソース、HTML、XMLなど、さまざまなリソースのエディタを提供します。



6.4 アプリケーションの配備6.4 アプリケーションの配備

「プロジェクトエクスプローラ」ビューの資産を選択して配備

配備ファイル

配備情報設定

設定された内容で配備

配備(Y)

WebDB.war

プロパティ(R)...

ワークベンチで作成したEJBアプリケーションやWebアプリケーションをアプリケーションサーバ上で動作させるために、資産を配備(Deployment)します。

資産を配備するには、以下の方法があります。

■プロジェクトエクスプローラビューの資産を選択して配備する

プロジェクトエクスプローラビューで資産(配備ファイル)を右クリックし、表示されるメニューより「配備」を選択し、資産を配備します。配備先の情報(配備先IJServerワークユニット)などは、配備ファイルのプロ

パティで設定できます。

■Interstage管理コンソールを利用して資産を配備する

Interstage管理コンソールを利用して資産を配備します。Interstage管理コンソールでは、IJServerの新規作成、削除および詳細設定ができます。

ワークベンチ上からInterstage管理コンソールを起動するには、IJServerビューで右クリックし、コンテキストメニューから「Interstage管理コンソール」を選択します。

■デバッグする前に資産を配備する

ワークベンチでは、「実行」メニューから「デバッグ」を選択し、作成したアプリケーションをデバッグ環境で動作させることができます。また、デバッグを開始する前に、資産を自動的に配備することが可能です。しかし、デバッグする前に資産を配備すると、デバッグを準備するのに時間がかかります。頻繁に変更しない資産は、パッケージエクスプローラビューの資産を選択して配備すると効率的に開発を進められます。

EJB JARファイルやWARファイルなどの資産をまとめたEARファイルでも、同様の手順でJ2EEアプリケーションとして配備(Deployment)することが可能です。



6.5 J2EEアプリケーションファイル6.5 J2EEアプリケーションファイル

J2EEプラットフォーム

EJBコンテナ

Servletコンテナ

クライアントコンテナ

J2EEアプリケーション

DD

DD

DD

DD

Deploy

EB EB

WebWeb

CLアプリ

・・・ JARファイル

・・・ WARファイル

・・・ EARファイル

・・・ deployment descriptorDD

EJBモジュール

DD

Webモジュール

DD

クライアントモジュール

DD

EBEB

WebWeb

Javaでは、作成したサーバサイドのアプリケーションを運用するには、配備（デプロイ：Deployment）する必要があります。EJBアプリケーションはJARファイルに、WebアプリケーションはWARファイルにパッケージ化し、デプロイする仕組みがとられます。さらにJ2EEでは、JARファイルやWARファイルを包含した形で、EARファイルとしてパッケージ化する仕組みが定義されています。

■JARファイルJava Archiveの略で、 Javaアプリケーションを構成するファイル群を1つのファイルに統合したものです。JavaBeansや、EJBアプリケーションをひとつのファイルにまとめる時にも使用されるファイル形式（拡張子は.jar）になります。

■WARファイルWeb application Archiveの略で、Webアプリケーションを含むJARファイルです。Webアプリケーションを構成するファイルすべてをjar形式でパッケージ化したファイル（拡張子は.war）になります。

■EARファイルEnterprise application Archiveの略で、J2EEアプリケーションを含むJARファイルです。EJB（JARファイル）、Webアプリケーション（WARファイル）、J2EEアプリケーションクライアントなどの組み合わせで構成されるアプリケーションをjar形式でパッケージ化したファイル（拡張子は.ear）になります。EARファイルとすることで、J2EEプラットフォームに、WebアプリケーションやEJBアプリケーションを一度に配備(Deployment) できます。



6.6 IJServerビュー6.6 IJServerビュー

【IJServer ビュー】

IJServerを表します。状態により異なるアイコンを表示します。上から起動、停止、デバック起動、停止処理または起動処理の状態です。また、左側のアイコンはスタンドアロンサーバに接続した際のIJServerで、右側のアイコンは管理サーバに接続した際のIJServerのアイコンです。

エレメントの文字列にはIJServer名を表示します。

IJServer

EJBアプリケーションまたはWebアプリケーションを表します。

エレメントの文字列には、EJBアプリケーションのEnterprise Bean名を表示し、WebアプリケーションのWebアプリケーション識別子を表示します。


配備ファイルを表します。

エレメントの文字列は配備ファイルのファイル名を表示します。上からEARファイル、EJB JARファイル、WARファイル、RARファイルです。V6.0で作成したIJServerの場合は、配備ファイルは表示されません。

配備ファイル

ローカルまたはリモートにあるInterstage Application Serverを表します。状態により異なるアイコンを表示します。上から起動、停止、停止処理または起動処理、未接続の状態です。また、左側のアイコンはスタンドアロンサーバに接続した際のアイコンで、右側のアイコンは管理サーバに接続した場合のアイコンです。未接続状態のアイコンは、スタンドアロンサーバと管理サーバで同じアイコンです。

エレメントの文字列にはホスト名を表示します。

Interstage ApplciationServer

説明アイコンエレメント

ワークベンチでは、ローカルまたはリモートにあるInterstage Application Serverの資産を表示し、これらの機能を操作することができるIJServerビューを提供しています。IJServerビューは、デフォルトでJ2EEパースペクティブとApcoordinatorパースペクティブに表示されます。

そのほかのパースペクティブでも、以下の手順で表示できます。

1. ワークベンチのメニューから[ウィンドウ] > [ビューの表示] >[その他]を選択します。

2. [ビューの表示]ダイアログボックスで [IJServer]を選択します。

IJServerビューを利用することで、Interstage Application Serverに関する以下の操作を、ワーク

ベンチ上から直接行うことができます。

■Interstage Application Serverの起動、停止

■IJServerの起動、停止

■IJServerに配備(Deployment)しているEJBアプリケーションやWebアプリケーションの表示

■IJServerに配備したEJBアプリケーションやWebアプリケーションの配備解除

■Interstage管理コンソールの表示(起動)


MEMO

第4章 Interstage Business Application...

Documents

Transcript of 第4章 Interstage Business Application...