処理形態

（1）バッチ処理

バッチ処理は，基本処理形態として1台のサーバ（スタンドアロン）上で実行される．

応用形態として同一のプログラムを，入力データを分散配置することで複数プロセス，

あるいは複数サーバ上で分散並列実行させることもあるが，プログラムとしては1本であ る．

図3-1 バッチ処理の基本形態

Figure 3-1 Basic model of the batch processing .

また生産性，保守性など品質向上を目的に，直列実行される一連の処理の流れを適切に プログラム分割することで，プログラム各々のロジックをシンプルにして見通しを良くし，

実行時は複数のプログラムをジョブ制御言語等で連結させて実行させる形態も一般的であ

Component X JOB control language or Batch control middleware

AP1 ^SAM _file Sort ^SAM _file AP2 ^SAM _file Sort ^SAM _file AP3

RDBMS

Database RDBMS

Database

34 る（図3-１）．

複数のバッチ処理を同時に実行させる場合には CPU やメモリ，ディスク容量などリ ソース割当ての最適化のためにリソース管理とジョブスケジュール機能を持つミドルウェ アを導入する例も多い．

バッチ処理は最も古い処理形態であり，メインフレーム時代からの技術蓄積も多く，本 ツールでもそれらノウハウの大部分を踏襲している[22]．バッチ処理は単位時間あたりの 処理件数を最大化する技術であるため，データ格納媒体は入力も出力も極力シーケンシャ ルファイルとなるようにデザインする．シーケンシャルファイルは一般に外部媒体への記 録方式としては単位時間当たりの読込みデータ量も書込みデータ量も最大である．

バッチ処理ではこのシーケンシャルファイルの性能を最大限に活かすため，アプリケー ション・プログラムが処理しやすい順序にソート処理を適宜挟んでシーケンシャルファイ ルを作り次のプログラムに送り，結果をまたその次のプログラムが処理しやすいように ソートを挟む．これを繰り返す形でバッチ処理全体を構成していくことがスループットを 最大化するポイントである．性能を最大化するためにRDBをはじめとするランダムアク セスを要するデータへのアクセスは必要最低限に留めるのもノウハウである．

図3-2 非同期実行向けアプリケーションテンプレート（基本構成A） Figure 3-2 Application template for asynchronous execution.

(Basic configuration A)

従来技術から加えるべきアプリケーション実装上のポイントは RDBMS へのアクセス 機能の充実である．

近年，スループットの最大化を狙うよりは，非同期処理の手段としてバッチ処理を利用

RDBMS

Component X JOB control language or Batch control middleware

Application program

Database

SAM files

35

するケースも多い．時間のかかる処理で画面の前のユーザを長い時間待たせるのではなく，

バックグラウンドに回し，複雑で時間のかかる処理をこなす．このような処理は対話処理 やオンライン処理と同等，あるいはそれ以上に複雑なデータベースアクセスを含む．また この処理を複数件のトランザクション分，一度に処理するケース（基本構成A）も多い．

対話処理やトランザクション処理から直接バッチ処理を非同期呼び出しする手もあるが，

データの引き渡しや起動ログの取得，多重度の制御などを行うため，MessageQueue や ファイル転送製品を使ってデータを渡す延長で起動させるケースが多くみられる．データ ベースにデータとキューを貯めて自動起動させる部品を自作するケースも多くみられる．

（2）対話処理とトランザクション処理

文献[15]では，2）対話処理と3）トランザクション処理の差は，アプリ実装時にトラン ザクション制御の有無で分類されているが，マルチユーザで利用するシステムは，ユーザ 間の処理が混信しないようにトランザクション制御を実装することが常識的であるため，

ここでは OLTP モニタ等トランザクション制御ミドルの有無によるアプリケーションソ フトウェア実装の差異として捉える．

図3-3 分散アプリケーション処理の基本モデル Figure 3-3 Basic model of distributed application processing.

対話処理やトランザクション処理を実装する場合は，少なくとも 2 つ以上の機器に股 がって実装されるアプリケーション間で処理分担を行う必要がある．課題は，機器間のア プリケーションの機能分担，トランザクション連鎖の範囲，通信プロトコルの3点に整理

Display Input

device

Visual programming language execution environment

Component X

Communication middleware Application program X

RDBMS Component Y

Communication middleware Application program Y

Database

Request

! Result

!

36 できる．

以下，利用者サイドに近い機器をX(component X)，データベースが接続されている機

器をY (component Y)として実装ケースを考える．