3.Javaバッチ実用化に向けたフレームワークの開発 - Nomura Research

NRI 技術創発
Java バッチ実用化に向けたフレームワークの開発
野村総合研究所
開発技術部上級テクニカルエンジニア
木村綾太郎（きむらりょうたろう）
情報技術本部にてオブジェクト指向技術を活用したシステム開発に取り組む IT エンジニ
ア。金融、産業、流通など様々な業界のシステム向けにミドルウエアフレームワークを開発。
これらの経験を生かして現在フレームワーク製品の開発業務に従事。
１．はじめに ................................................................................................................. 43
２．バッチ開発の現状と Java バッチへの期待の高まり ........................................ 43
３．Java バッチの性能向上への取り組み ................................................................ 44
４．Java バッチの生産性向上への取り組み ............................................................ 56
５．様々な Java バッチ処理方式への対応 ............................................................... 66
６．おわりに ................................................................................................................. 68
要旨
現状では、オンラインアプリケーションを Java 言語で開発していても、バッチアプリケーションは従来通り COBOL
言語で開発するという事例が多い。この主な理由は、Java バッチ（Java 言語によるバッチ処理）に対する性能面での不
安が大きいためであると考えられる。一方で、生産性向上へのさらなる要求、COBOL 技術者確保への不安、Java 実行
環境の性能向上等を受けて Java バッチへの期待は高まりつつある。
このような状況を受けて、筆者らは、Java バッチの実用化に向けた取り組みを行った。まず、Java バッチの性能向上
を目指した RI（Record Item）フレームワークを開発し、Java バッチの性能を COBOL バッチと同等以上にまで引き上
げられることを確認した。また、設計モデルに DFD を採用し、DFD の段階的詳細化により設計を行う手法により生産
性向上を目指した FCI（Flow Control Injection）フレームワークを開発した。以上の取り組みにより、Java バッチ実
用化に対する目処が立ったと考える。
キーワード： Java、COBOL、バッチ、2007 年問題、フレームワーク、DFD、ディレードオンライン、センターカット
Currently there are a lot of cases which even while online application is developed by Java language, batch
application is still developed by COBOL language.The main cause should be uncertainty of Java batch
performance, which is batch process using Java language. On the other hand, due to higher demand for
productivity improvement, uncertainty of securing COBOL engineers, following performance improvement of
Java runtime environment, expectation of Java batch is growing.
Under this situation, we took an approach toward the practical use of Java batch. First of all, we developed RI
(Record Item) framework which worked toward performance improvement, confirmed to be able to improve
performance of Java batch same as or more than COBOL batch.And we developed FCI (Flow Control
Injection) framework which worked toward performance improvement through bringing in DFD as design
model and design method using stepwise refinement of DFD. This approach shows the practical use of Java
batch has good prospects.
Keyword : Java, COBOL, Batch, Year 2007 problem, Framework, DFD, Delayed online, Center cut
42
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2007 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
Java バッチ実用化に向けたフレームワークの開発
１．はじめに
現在、大規模システム構築においてバッチ
ションとバッチアプリケーションを共に
COBOL 言語で開発していた時代のように、
処理を Java 言語で開発するという事例はま
開発言語を Java 言語に統一することが望ま
だまだ少ない（本稿では、バッチ処理を、
「大
れるところである。
量のデータに対して一括処理を行う処理方
あえて、バッチアプリケーションを従来通
式」の意味で用いる）。一方で、COBOL 技術
り COBOL 言語で構築する主な理由は、以下
者確保への不安などを背景として、Java バッ
の２つであると考えられる。
チ（Java 言語によるバッチ処理）に対する期
待は高まりつつある。
このような状況を受けて、筆者らは、Java
¡Java バッチに対する性能面の不安
インタープリタ型の言語であるため Java の
バッチ実用化へ向けた以下のような取り組み
実行速度は非常に低いという先入観から、
を行った。
Java のバッチ処理への適用は敬遠されてき
た。そのため、実際のバッチアプリケーショ
¡
Java バッチの性能向上への取り組み
ンを使っての性能測定や性能向上のための
¡
Java バッチの生産性向上への取り組み
工夫が行われて来なかった。この結果、Java
¡
様々な Java バッチ処理方式への対応
によるバッチ処理は遅いという先入観は拭
われず、その適用が見送りになる状況が続
本稿では、これらの取り組みについて報告
いて来た。
する。
¡COBOL の生産性で十分という認識
２．バッチ開発の現状と Java バッチへの
COBOL 言語が利用されてきた歴史は古
期待の高まり
く、多くのリソースやノウハウの蓄積があ
（１）バッチ開発の現状
る。このため、COBOL 言語によるバッチ
現在、Web アプリケーションが一般化し
開発の生産性は高い。このような状況で、
たことにより、多くのプロジェクトがオンラ
あえて未知の Java 言語によるバッチ開発
インアプリケーションを Java 言語で構築す
にチャレンジしようとするプロジェクトは
るようになった。一方で、このようなプロジ
ほとんどなかった。
ェクトであってもバッチアプリケーションは
従来通り COBOL 言語で構築している場合が
多い。本来であれば、オンラインアプリケー
（２）Java バッチへの期待の高まり
筆者らは、以下に示すようなシステム開発
43
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2007 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
NRI 技術創発
を取り巻く様々な環境の変化を受けて、Java
ール、テスト自動化ツール等の新しい開発
バッチに対する期待は高まっていると考える。
技術は、Java 開発を取り巻くオープンソー
スプロジェクトから生み出されている。
¡生産性向上へのさらなる要求
Java 言語により開発を行っておけば、これ
システム構築における短納期、低コスト開
らの開発技術を速やかに取り込み、生産性
発に対する要求はますます高まりつつあ
の向上に結びつけることができる。
り、これまでの生産性を「飛躍的」に向上
させる必要がある。
３．Java バッチの性能向上への取り組み
（１）性能向上への取り組みの概要
¡COBOL 技術者確保への不安
一般に「2007 年問題」と言われている団塊
Java バッチの性能向上を目指して以下の
ような取り組みを行った。
世代の大量退職が始まることで、これまで
COBOL 開発を支えてきた技術者の確保が
困難となることが予想される。また、一般
①現状の Java バッチ性能の把握
COBOL バッチを比較対象とし、性能向上
化しつつあるオフショア開発においても、
のための工夫を行わない状態で Java バッチの
Java 技術者に比べて COBOL 技術者の確保
性能を測定した。Java バッチは、COBOL バッ
が難しいという状況がある。
チと同様にファイル受け渡しのアーキテクチ
ャで実装した。性能測定の結果、Java バッチ
¡Java 実行環境の性能／信頼性向上
Java 実行環境に対する性能向上への取り
の性能は低いが工夫により COBOL バッチに
追い付けるレベルであることがわかった。
組みは、継続的に行われている。例えば、
インタープリタ実行の欠点を克服するため
②性能向上のための実装アーキテクチャの
の HotSpotVM 技術の登場により、Java の
選定
実行速度は以前に比べて大幅に向上してい
処理間のデータ受け渡しの実装方式とし
る。また、Web アプリケーションサーバで
て、ファイル方式、RDB 方式、メモリ方式の 3
の稼動実績が蓄積されてきたことにより、
つの方式をリストアップし、これらを比較す
安定性・信頼性ともに向上してきている。
るための性能検証を行った。検証の結果、フ
ァイル受け渡し方式を採用することとした。
¡新たな開発技術の登場
AOP（アスペクト指向プログラミング）ツ
44
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2007 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
Java バッチ実用化に向けたフレームワークの開発
③性能向上を目指したフレームワークの開発
ファイル受け渡しの方式を前提に、ファイ
¡指標として適切なバッチアプリケーション
を用いること
ル入出力を行う Java バッチの性能を向上さ
実プロジェクトでサーバのサイジングに用
せるフレームワークを開発した。
いられているバッチアプリケーションを借
用し、性能測定の対象とした。このアプリ
④性能向上効果の検証
性能向上のためのフレームワークを適用し
ケーションは典型的なバッチ処理を実装し
たものであり、データ量も実システムを想
た上で、再度 Java バッチの性能を測定した。
定したものとなっている。アプリケーショ
フレームワークの効果により、COBOL バッ
ンは COBOL 言語で実装されていたため、
チと同等以上にまで Java バッチの性能を向
これを Java バッチへ移植した上で性能を
上させることが可能なことがわかった。
比較した。
以下、これら性能向上への取り組みについ
て詳しく説明する。
¡Java バッチへの移植においてプログラム
ロジックを変更しないこと
ありのままの Java 実行環境の性能を測定
（２）現状の Java バッチ性能の把握
することが目的であるため、移植において
筆者らは、まず、現状の Java バッチ性能の
性能を向上させるような特別な工夫は行わ
把握から始めることとした。Java バッチの性
なかった。つまり、
「ファイル受け渡しから
能測定を行う上で、考慮したポイントは以下
メモリ受け渡しへ変更する」ようなプログ
の通りである。
ラムロジックの変更は行わなかった。よっ
て、これまでの COBOL バッチと同様の設
¡COBOL バッチを比較対象とすること
計手法で Java バッチを開発した場合の性
現在でも多くのバッチ処理は COBOL 言語
能指標が得られることになる。ただし、最
で実装されている。よって、Java バッチの
新の Java 実行環境が備える性能向上技術
性能を COBOL バッチとの性能比で示すこ
（NewIO 等）については、これを利用した
とが多くのバッチ開発者にとってわかりや
上で移植を行った。
すい指標となると判断した。
以上のポイントを考慮した上で、COBOL
バッチ、Java バッチを用意し性能測定を行っ
た。性能測定の環境は以下の通りである。
45
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2007 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
NRI 技術創発
¡
性能測定の結果、現状の Java バッチの性
ソフトウエア
COBOL ： COBOL2002
能は COBOL バッチと比較して、以下のよう
Java ： SUN JRE1.4.2
になった。
（処理時間は多重度が 1 の場合）
OS ： Windows Server 2003
処理時間： 2.56 倍
¡
スループット： 0.4 倍
ハードウエア
機種： HA8000/130
予想通り Java バッチの性能が低いことが
CPU ： Xeon 3.4GHz × 2
メモリ： 2GByte
わかったが、その差は 3 倍以内であり、性能
ディスク： 36G × 3
向上のための工夫によりこの課題を解決でき
3500000
処理時間(ms)
3000000
2500000
2000000
1500000
COBOL
バッチ
1000000
Java
バッチ
500000
0
5
10
15
多重度
スループット(ジョブ/h)
図 1 現状の処理時間
50
COBOL
バッチ
40
Java
バッチ
30
20
10
0
5
10
15
多重度
図 2 現状のスループット
46
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2007 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
Java バッチ実用化に向けたフレームワークの開発
¡ファイル方式
る可能性が高いと判断し、以降の取り組みを
中間ファイルを使って、データを受け渡す
行うこととした。
方式。
¡RDB 方式
（３）性能向上のための実装アーキテクチャの
選定
RDB 上のテーブルを使って、データを受け
渡す方式。
①実装アーキテクチャの検討
¡メモリ方式
次に、性能向上を目指した Java バッチの実
装アーキテクチャの検討を行った。アーキテ
メモリ上のオブジェクトを使って、データ
クチャ選定のための候補として、一般によく
を受け渡す方式。
知られている POSA アーキテクチャパターン
②実装方式決定のための性能検証
分類（『ソフトウエアアーキテクチャ』F.ブッ
Pipe 部分の実装方式を選定するために、
シュマン他著）を用いることとした。この中
からバッチ処理に適しているとされる「Pipes
Pipe 部分にファイル、RDB、メモリを利用し
and Filters パターン」をベースに検討を行っ
た 3 つのパターンのプログラムを作成し、性
た。Filter 部分は、業務処理そのものであり一
能測定を行った。
また、バッチ処理において必ず必要となる
概に性能向上のための実装方式を規定するこ
とができない。一方、Pipe 部分は、データを
ソート処理を Pipe 部分の機能として捉えて、
処理から処理へと受け渡す汎用的な部分であ
Pipe 部分でソート処理を行うパターンのプロ
り、性能向上のための実装方式を規定するこ
グラムも作成し、合わせて性能測定を行った。
とが可能である。そこで、Pipe 部分の実装方
それぞれソート処理は以下のように実装した。
式の候補をリストアップした上で、実機上で
¡ファイル方式
の性能検証を行い、最適な実装方式を選定す
ることにした。Pipe 部分の実装方式の候補と
ソートユーティリティを外部コマンドとし
して、以下の 3 つをリストアップした。
て呼び出し、ソート処理を実行。
Data Source
Filter 1
Pipe 1
Filter 2
Pipe 2
Data Sink
Pipe 3
図 3 Pipes and Filters パターン
47
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2007 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
NRI 技術創発
¡RDB 方式
性能測定の結果を、表 1、表 2 に示す。
SQL の「ORDER BY 句」を利用し、データ
読み込みと同時にソート処理を実行。
③ 実装アーキテクチャの選定
¡メモリ方式
Pipe 部分の実装方式決定のための性能検
Java 実行環境が備える Collection ライブラ
証の結果を受け、以下のように考察した。
リを利用し、ソート処理を実行。
¡RDB 方式の性能は非常に低い
ほとんどのパターンで、RDB 方式の性能は
これらの性能検証パターンを、図 4 に示した。
■ソートなし
ファイル
ステップＡ
ファイル
ステップＢ
DBテーブル
ステップＡ
テーブル
ステップＢ
オブジェクト
ステップＢ
Javaオブジェクト
ステップＡ
■ソートあり
ファイル
ステップＡ
ファイル
sortツール
ファイル
ステップＢ
DBテーブル
ステップＡ
テーブル
ステップＢ
select … from … order by
Javaオブジェクト
ステップＡ
オブジェクト
ステップＢ
Collectionクラスでソートを実装
ファイル生成開始からファイル入力終了までを計測
図 4 実装方式検証ジョブパターン
48
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2007 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
Java バッチ実用化に向けたフレームワークの開発
サイズ
10K
サイズ
100K
サイズ
1M
サイズ
10M
サイズ
100M
種別／多重度
1
2
4
8
ファイル
DB
Javaオブジェクト
0.011
0.138
0.004
0.005
0.196
0.003
0.004
0.355
0.003
0.006
0.720
0.003
種別／多重度
1
2
4
8
ファイル
DB
Javaオブジェクト
0.050
0.447
0.043
0.074
0.625
0.040
0.056
1.068
0.052
0.064
2.159
0.048
種別／多重度
1
2
4
8
ファイル
DB
Javaオブジェクト
0.330
3.433
0.257
0.496
5.372
0.397
種別／多重度
1
2
ファイル
DB
Javaオブジェクト
種別／多重度
ファイル
DB
Javaオブジェクト
3.100
34.868
2.572
1
4.716
56.790
3.484
2
30.902
462.740
21.433
40.520
711.766
46.133
0.938
10.420
0.378
4
8.856
123.073
5.546
4
1.620
19.543
0.466
8
16.483
230.793
5.201
8
16
0.006
1.418
0.003
16
0.074
4.682
0.043
16
2.273
40.505
0.436
16
32.635
545.967
8.718
16
78.770
167.556
512.896
1249.145
2831.931
5663.862
OutOfMemoryExceptionで計測不能
表 1 処理時間（ソートなし）
サイズ
10K
サイズ
100K
サイズ
1M
サイズ
10M
サイズ
100M
種別／多重度
ファイル
ＤＢ
Javaオブジェクト
1
2
4
8
0.056
0.138
0.005
0.071
0.178
0.004
0.346
0.333
0.003
0.507
0.706
0.003
種別／多重度
ファイル
ＤＢ
Javaオブジェクト
1
2
4
8
0.113
0.452
0.037
0.148
0.635
0.045
0.367
1.057
0.061
0.879
2.132
0.053
種別／多重度
ファイル
ＤＢ
Javaオブジェクト
1
2
4
8
0.501
3.448
0.267
0.849
5.586
0.406
種別／多重度
ファイル
ＤＢ
Javaオブジェクト
1
2
4.194
42.918
2.619
種別／多重度
ファイル
ＤＢ
Javaオブジェクト
30.742
593.934
22.361
1
6.430
82.265
4.535
2
46.668
1077.847
48.292
1.009
10.453
0.431
4
11.358
161.568
7.825
4
2.395
19.797
0.446
8
17.350
334.432
9.256
8
16
1.337
1.470
0.003
16
2.200
4.726
0.049
16
3.802
46.810
0.593
16
24.045
937.767
9.682
16
90.271
334.620
1130.288
1976.572
3588.000
7175.000
OutOfMemoryExceptionで計測不能
表 2 処理時間（ソートあり）
49
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2007 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
NRI 技術創発
他のファイル方式、メモリ方式に比べて非
ジェクト生成処理を削減することも性能向上
常に低く（約 1/10）なっている。RDB が得
のポイントとなる。
意とするソート処理を含むパターンの場合
でも、この傾向は変わらない。
しかし、これらの性能向上のためのポイン
トを踏まえて設計を行うことは難しく、また、
開発者ごとのバラツキも出やすい。そこで、
¡ファイル方式とメモリ方式の性能差は小さい
筆者らは、あらかじめ性能向上のための工夫
OS 側のファイルキャッシュが有効に働く
を取り入れた RI（Record Item）フレームワ
ため、ファイル方式とメモリ方式との性能
ークを開発した。RI フレームワークでは、レ
にはほとんど差がない。
コード形式でのデータ入出力とデータ保持の
機能を提供している。
¡データ量増加に対応できるのはファイル方式
メモリ方式は、物理メモリ量の制約を受け
るため、データ量と多重度の増加に対応で
きない。
② RI フレームワークの性能向上手法
RI フレームワークでは、以下の 2 つの性能
向上手法を用いて Java バッチの性能向上を
図っている。
以上の考察から、Pipe 部分の実装方式はフ
ァイル方式が最適であると判断できる。まと
¡バイト列のままデータを保持する
めると、性能向上を目指した Java バッチの
通常の Java プログラミングでは、データ
実装アーキテクチャには、
「Pipe 実装にファ
レコードを入力するたびに個々のデータ項
イルを用いる Pipes and Filters アーキテクチ
目に対するオブジェクトを生成する。バッ
ャ」が最適であるとの結論に達した。
チ処理の場合は扱うデータ量が非常に大き
いため、このような方法ではオブジェクト
（４）性能向上を目指したフレームワークの
開発
① RI（Record Item）フレームワークの開発
生成の回数が極端に増え、性能低下を招く。
RI フレームワークでは、データレコードを
格納するオブジェクトを用意しておき、デ
Pipe 部分の実装にファイルを用いる Pipes
ータレコード入力時には内部のバイト配列
and Filters アーキテクチャにおいては、ファ
のみを書き換える。これにより、データ量
イル入出力に伴うデータ変換処理を削減する
に関わらず、オブジェクト生成を一度だけ
ことが性能向上のポイントとなる。また、大
行えばよい仕組みとなっている。
量データを扱うバッチ処理の特性から、オブ
50
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2007 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
Java バッチ実用化に向けたフレームワークの開発
¡必要な部分のみ数値・文字列変換する
換処理を行わずにバイト列のまま比較する
通常の Java プログラミングでは、データ
等の方法によっても、変換処理を削減して
レコードを入力するたびに個々のデータ項
いる。
目に対する数値オブジェクト、文字列オブ
ジェクトを生成する。つまり、入力のタイ
ミングですべてのデータ項目に対して数
値、文字列変換が行われる。ところが、バ
③ RI フレームワークの機能
RI フレームワークの機能の一覧を表 3 に
示す。
ッチ処理の対象はデータレコードの一部の
みであることが多く、すべてのデータ項目
に対して変換処理を行うことは非常に無駄
④ RI フレームワークによる開発イメージ
RI フレームワークでは、データレコードを
が多い。
Java クラスとして定義する。これを、レコー
RI フレームワークでは、データレコードを
ド定義クラスと呼んでいる。レコード定義ク
バイト配列のまま保持しておき、実行時に
ラスのコーディング例を図 6 に示す。レコー
必要となったデータ項目のみを数値、文字
ド定義クラスの利用方法を示すコーディング
列変換する方法を取っている。
例を図 7 に示す。
また、同一データ型の項目同士の比較は変
入力
123.92
従来
手法
3e 29 40 1c 32 …
変換処理
バイト列
インスタンス
生成
出力
Javaメモリ領域
入力
3e 29 40 1c 32 …
バイト列
ヨコハマ
文字列オブジェクト
外部データストア
RI
手法
数値オブジェクト
出力
インスタンス
生成は
一度だけ
3e 29 40 1c 32 …
バイト列
RIオブジェクト
変換処理
ヨコハマ
外部データストア
Javaメモリ領域
図 5 RI フレームワークの性能向上手法
51
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2007 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
NRI 技術創発
クラス
機能
データ保持クラス
説明
バイト配列保持
データをバイト配列で保持することで、文字コード、フォーマット変換を排除。
データ構造
階層型、繰り返し型のデータ構造をサポートし、一般的な業務データ構造にフィット。
JavaBeansインター
RecordItemクラスを用いながら、オンライン処理と同一のインターフェイスを提供する。
フェイス
中間ファイルクラス
DBアクセスクラス
ファイルアクセス
Fileクラスのラッパーとしてファイルアクセス機能を提供する。
RecordItem I/F
RecordItemクラス単位での入出力機能を提供する。
RecordItem I/F
RecordItemクラス単位でのDBアクセス機能を提供する。
表 3 RI フレームワークの機能一覧
public class RI_Date extends RecordItem {
public RI_PicX yy = new RI_PicX(2);
public RI_PicX mm = new RI_PicX(2);
public RI_PicX dd = new RI_PicX(2);
public RI_Date() {
this.add(this.yy);
this.add(this.mm);
this.add(this.dd);
}
}
図 6 レコード定義クラス例
public void testRecordItem() {
// RI のインスタンス生成と初期化
RI_Date date1 ＝ new RI_Date();
date1.initializeRecord();
RI_Date date2 ＝ new RI_Date();
date2.initializeRecord();
// RI へのデータのセット
date1.setString("060718"); // レコードを一度に
date2.yy.setString("06"); // 項目別に
// RI と RI の比較（バイナリ比較）
if (date1.yy.equals(date2.yy)) {
// RI から RI へのコピー（バイナリコピー）
date1.mm.moveTo(date2.mm);
date1.dd.moveTo(date2.dd);
}
}
図 7 レコード定義クラス利用例
52
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2007 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
Java バッチ実用化に向けたフレームワークの開発
¡COBOL バッチ
（５）性能向上効果の検証
「現状の Java バッチ性能の把握」で用いた
①性能測定の内容
RI フレームワークによる性能向上効果を
COBOL バッチから一部を取り出し、測定対
検証するため、フレームワーク適用後の Java
象とした。
（今回は、Java バッチを COBOL
バッチを用意し再度、性能測定を行った。今
バッチからの単純移植ではなく、再構築に
回も、前回と同様に COBOL バッチを比較対
より開発することになる。よって、開発期
象とするため、COBOL バッチ、Java バッチ
間の短縮を目的に、対象とする COBOL バ
両方のバッチプログラムを作成し、これらの
ッチの範囲を絞った。ただし、典型的なバ
性能を測定した。
ッチ処理を含むように範囲設定した。
）
なお、後述する生産性向上のための FCI フ
¡Java バッチ
レームワークについても、同時に適用した上
で Java バッチの性能測定を行っている。こ
COBOL バッチの外部仕様をリバースエン
れは、FCI フレームワークにも一部性能向上
ジニアリングにより抽出した上で、この外
が見込まれる機能が含まれるからである。
部仕様に基づく Java バッチを、フレーム
ワークを利用し再構築した。
測定対象としたバッチプログラムは、それ
ぞれ以下のものである。
COBOL バッチ、Java バッチの処理フロー
を図 8 に示す。
COBOLバッチ
500000件
data.AB.MA.101
3999992件
499999件
SEVPFURD
data.AB.OUT_201
499999件
SEVPFURE
data.CD.OUT_S.201
data.AB.TR.101
Javaバッチ
3999992件
data.AB.TR.101
Uriage
Aggregetor
MiseMa
Matcher
499999件
data.CD.OUT_S.201
data.AB.MA.101
500000件
図 8 処理フロー
53
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2007 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
NRI 技術創発
COBOL バッチと比較して以下のようになっ
J a v a バッチは、中間ファイル（ d a t a .
た。
（処理時間は多重度が 1 の場合）
AB.OUT_201）を利用しない処理フローとな
っている。これは、後述する FCI フレームワ
処理時間： 1/3 倍
ークの中間ファイル削除機能の効果である。
スループット： 4 倍
バッチプログラムの入出力ファイルを表 4
に示す。入出力ファイルの合計サイズは約
よって、性能向上を目指したフレームワー
1GB であり、実システムを想定したデータ量
クの適用により、J a v a バッチの性能は
となっている。
COBOL バッチと同等以上にまで向上するこ
性能測定に利用したハードウエア、ソフト
とがわかった。
ウエアを図 9 に示す。今回も、同一のハード
また、フレームワークに組み込まれた性能
ウエア上で、COBOL バッチ、Java バッチの
向上手法の効果を個別に測定した結果を表 5
性能測定を行った。
に示す。これによると、オブジェクトの再利
用（オブジェクト生成処理の削減）が、Java
②性能測定の結果
バッチの性能向上に最も効果があることがわ
性能測定の結果、J a v a バッチの性能は
I/O
入出力ファイル
データ内容
I
data.AB.MA.101
店マスタ
I
data.AB.TR.101
売上データ
O
data.AB.OUT_201
O
data.CD.OUT_S.201
件数
レコード長
ファイルサイズ(KB)
500000件
1200
585,938
3999992件
20
195,313
店別売上中間データ（COBOLのみ）
499999件
256
125,000
店別売上データ
499999件
256
125,000
表 4 入出力ファイル
IAサーバ
COBOLバッチ
Javaバッチ
COBOL2002 Net Developer
JDK（1.5.0_06 ）
Windows Server 2003 Standard Edition
HA8000
(Xeon3.6GHz/3.37GMem/2CPU)
図 9 性能測定環境
54
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2007 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
Java バッチ実用化に向けたフレームワークの開発
700000
処理時間(ms)
600000
500000
400000
300000
200000
COBOL
バッチ
100000
Java
バッチ
0
2
4
6
8
10
12
14
16
18
多重度
図 10
性能向上後の処理時間
500.000
450.000
スループット(件/h)
400.000
350.000
COBOL
バッチ
300.000
250.000
Java
バッチ
200.000
150.000
100.000
50.000
0.000
0
2
4
6
8
10
12
14
16
18
多重度
図 11
カテゴリ
RIフレームワーク
FCIフレームワーク
性能向上後のスループット
性能向上手法
削減時間
削減率
オブジェクトの再利用
−67.2秒
−83.5％
データ変換処理の削減
−23.8秒
−64.2％
−1.7秒
−13.0％
−92.7秒
−88.7％
中間ファイルI/Oの削除
合計
表 5 手法ごとの性能向上効果
55
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2007 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
NRI 技術創発
かった。
開発手法を検討した結果、設計モデルに
DFD（データフローダイアグラム）を採用し
③性能向上効果のまとめ
性能向上のためのフレームワークを適用す
DFD の段階的詳細化により設計を行う手法
を選定した。
る前の Java バッチの性能は、COBOL バッチ
と比較して、
（処理時間は多重度が 1 の場合）
②生産性向上を目指したフレームワークの開発
DFD を中心とした開発アーキテクチャを
処理時間： 2.56 倍
前提に、生産性向上を目指したフレームワー
スループット： 0.4 倍
クを開発した。
であったが、フレームワークの適用により、
③導入支援ドキュメントの整備
フレームワーク導入を支援し、生産性向上
処理時間： 1/3 倍
に繋げるための各種ドキュメントを検討し、
スループット： 4 倍
その一部を作成した。
にまで向上した。つまり、フレームワーク
の適用により約 10 倍の性能向上効果が得ら
れたことになる。
また、COBOL バッチと同等以上の性能を
④最新の開発技術導入の可能性
Java 言語でバッチ開発することで可能と
なる最新の開発技術／ツールの導入について
検討した。
発揮できることが確認されたことで、Java バ
ッチの性能面での不安はほぼ解消されたと考
える。
４．Java バッチの生産性向上への取り組み
（１）生産性向上への取り組みの概要
Java バッチの生産性向上を目指して以下
のような取り組みを行った。
以下、これらの生産性向上への取り組みに
ついて詳しく説明する。
（２）開発アーキテクチャの選定
Java によるオンラインアプリケーションの
開発では、生産性、品質の向上を目指したフ
レームワークを使って開発を行う方法が一般
化している。筆者らは、バッチアプリケーシ
①開発アーキテクチャの選定
Java バッチの生産性向上を目指した設計
ョンにおいても同様のアプローチが有効であ
ると考え、Java バッチ開発の生産性向上を目
56
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2007 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
Java バッチ実用化に向けたフレームワークの開発
指したフレームワークを開発することにした。
そこで、まず Java バッチの開発アーキテ
クチャ（設計開発の手法）について検討を行
上記の要件を重視し検討を行った結果、
Java バッチの開発アーキテクチャを以下の
ように決定した。
った。検討にあたって、以下の 2 つの要件を
¡設計モデル： DFD を採用
重視した。
バッチアプリケーションの設計モデルとし
¡設計手法がシンプルでわかりやすいこと
て DFD を一貫して採用する。DFD ではデ
バッチ処理は、データの流れとデータに対
ータの流れに着目して設計情報をモデル化
する処理の組み合わせとして捉えるとわか
するため、バッチ処理を自然に表現するこ
りやすい。バッチ処理の設計モデルでは、
とができる。
これを自然に表現できる必要がある
¡設計手法： DFD の段階的詳細化により設
¡設計情報のトレーサビリティが確保される
計を行う
こと
上流工程から下流工程まで、DFD を段階
上流工程と下流工程の設計情報の紐付けを
的に詳細化することにより設計を行う。こ
容易に把握できることが重要である。これ
れにより、DFD をキーとして設計情報の
により、上流工程で発生した仕様変更を下
トレーサビリティを確保することが可能と
流工程の設計情報に迅速に反映させること
なる。段階的詳細化のイメージを、図 12 に
が可能となる。また、下流工程（例えば、連
示す。
結テスト中）で発見された仕様の不整合を
上流工程の設計情報に遡って修正すること
が容易に行えるようになる。
図 12
DFD の段階的詳細化
57
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2007 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
NRI 技術創発
¡開発手法： DFD 構成要素と開発モジュー
DFD のモデル要素は、そのまま実装すべ
ルとの対応付け
きクラスに対応する。つまり、FCI フレー
下流工程の DFD モデル図の構成要素が、
ムワークを利用した開発では、DFD の詳
そのまま開発モジュールに対応付けられる
細化を行うことでクラス設計までの設計作
ようにする。これにより、モジュール分割
業が完了することになる。
のための設計を別途行う必要がなくなる。
また、設計情報だけでなく開発モジュール
¡業務ロジックとフロー制御ロジックの分離
までも含めたトレーサビリティの確保が容
フロー制御ロジック（データの受け渡し制
易に行えるようになる。
御やマッチング制御等）は、FCI フレーム
ワークが提供する。よって、バッチアプリ
（３）生産性向上を目指したフレームワークの
開発
①FCI（Flow Control Injection）フレームワ
ケーションの開発者は純粋な業務ロジック
のみを実装するだけでよい。これに加えて、
FCI フレームワークではフロー制御ロジッ
ークの開発
クを実行時に交換可能な仕組みとしてい
DFD を中心とした開発アーキテクチャを前
る。これを、フロー制御ロジックの注入
提に、Java バッチ開発の生産性向上を目指し
（Flow Control Injection）と呼んでいる。
た FCI（Flow Control Injection）フレームワー
フロー制御ロジックを変更するにあたって
クを開発した。なお、FCI フレームワークの実
は、バッチアプリケーション側の修正は一
行制御手法については特許出願中である。
切不要である。
現在、フロー制御ロジックとして、シング
② FCI フレームワークの特徴
FCI フレームワークの特徴を以下に示す。
ルスレッド制御とマルチスレッド制御の 2
つを提供しているが、将来はグリッド実行
制御（複数のサーバによる分散処理）を提
¡DFD からクラス設計へのダイレクトマッ
供することも可能である。
ピング
FCI フレームワークを前提とした設計で
¡不要な中間ファイルの削除
は、入力処理、出力処理、マッチング処理、
フロー制御ロジックを FCI フレームワーク
集約処理（ブレーク処理）の 4 つの処理の
が提供することにより、プログラムのメイ
みから構成される状態となるまで、DFD
ンループはアプリケーションからフレーム
を段階的に詳細化する。詳細化が完了した
ワーク側に移動することになる。FCI フレ
58
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2007 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
Java バッチ実用化に向けたフレームワークの開発
ームワークのフロー制御ロジックでは、処
プリケーション（DFD）を分離することに
理から処理へ直接データの受け渡しを行う
なる。
ため、データの受け渡しだけを目的とした
③ FCI フレームワークを利用した開発の概要
不要な中間ファイルを削除することができ
FCI フレームワークを利用したバッチアプ
る。このイメージを図 13 に示す。
リケーション開発の概要を以下に示す。
また、これによって、DFD 上ではプロセス
とプロセスの間を直接データの流れとして
結ぶことができ、シンプルな DFD を使っ
a バッチ処理の DFD によるモデル化
て設計することが可能となる。
バッチアプリケーションが対象とする業務
ただし、ジョブのリランポイントとするた
処理を DFD によりモデル化する。
めに中間ファイルを利用している場合や、
中間ファイルでソート処理を行う場合は、
これらを削除することはできない。この場
b プロセスの詳細化
DFD 中のプロセスに着目し、段階的に詳
合は、この中間ファイルの前後でバッチア
細化した DFD を作成する。
ループ
ループ
入力処理A
入力処理B
加工処理A
加工処理B
出力処理A
出力処理B
入力処理A
加工処理A
加工処理B
出力処理B
ループ
図 13
不要な中間ファイルの削除
59
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2007 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
NRI 技術創発
④ FCI フレームワークを利用した開発の流れ
c 集約処理（ブレーク処理）の詳細化
複数レベルでのブレーク処理を含む複雑な
集約処理をさらに詳細化する。
a バッチ処理の DFD によるモデル化
バッチアプリケーションを含む業務処理全
体を DFD によりモデル化する。この DFD で
d 詳細化 DFD を元に設計、コーディング
詳細化が完了した DFD をもとに、詳細設
は、概要設計もしくは外部設計レベルの設計
情報を整理し表現する。DFD の作成にあた
計、コーディングを行う。
っては、表 6 で示すような一般的な記法を用
いる。
e フロー制御ロジックの注入
完成したバッチアプリケーションに対して
概要レベル DFD の例を図 15 に示す。
フロー制御ロジックを注入する。
b プロセスの詳細化
a. バッチ処理のDFDによるモデル化
DFD 中の特定のプロセスに着目し、プロ
セスの内部で実行される業務処理を詳細化し
b. プロセスの詳細化
c. 集中処理（ブレーク処理）の詳細化
た別の DFD を作成する。これを DFD 中の
各々のプロセスについて行うことで、DFD
d. 詳細化DFDを元に設計・コーディング
の段階的詳細化を行う。最終的に、DFD の構
e. フロー制御ロジックの注入
図 14
FCI を利用した開発の流れ
成要素が、入力処理、出力処理、マッチング
処理、集約処理（ブレーク処理）の 4 つの処理
のみの状態となるまで詳細化を行う。
名称
シンボル
説明
源泉と吸収
DFDにデータが流れ込む元と、DFDからデータが流れ出す先を示す。
利用者や外部システムが相当する。
データストア
データの一時的な保存場所を示す。
ファイルやデータベースが相当する。
プロセス
データに対して適用する業務処理を示す。
データフロー
データの流れを示す。
表 6 DFD の記法
60
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2007 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
Java バッチ実用化に向けたフレームワークの開発
用して表現する。
（例：売上データの中の
4 つの処理の意味を以下に示す。
店コードをキーに店マスタを突き合わせて
¡入力処理
店名を追加する処理）
ファイルやデータベースからの単純な入力
突き合わせ元のストリームをトランザクシ
処理を示す。源泉のシンボルを利用して表
ョンストリーム、突き合わせ先のストリー
現する。データストアからの入力は、デー
ムをマスターストリームと呼び、2 つのスト
タストアのシンボルを使わず、この入力処
リームを区別する。DFD 上では、これらを
理として表現する。つまり、データストア
区別するためにデータフローの矢印の近く
を含む DFD はデータストアを境として別
に「TR Stream」
、
「MA Stream」と記述する。
の DFD に分離されることになる。
¡集約処理（ブレーク処理）
¡出力処理
1 つのストリーム（データの流れ）から入力
ファイルやデータベースへの単純な出力処
されたデータを特定のキー（ブレークキー）
理を示す。吸収のシンボルを利用して表現
で集約することによって行う業務処理を示
する。データストアへの出力は、データス
す。プロセスのシンボルを利用して表現す
トアのシンボルを使わず、この出力処理と
る。
（例：売上データの中の地区コードをキ
して表現する。
ーに地区ごとの売上合計を集計する処理）
¡マッチング処理
詳細化が完了した DFD の例を図 16 に示
2 つのストリーム（データの流れ）から入力
す。この DFD は、図 15 の中にある「売上集
されたデータを特定のキー（マッチングキ
計プロセス」を詳細化したものである。
ー）により突き合わせることによって行う
詳細化が完了した DFD には、FCI フレー
業務処理を示す。プロセスのシンボルを利
ムワークのモデル要素との対応が分かり易い
売上集計データ
店舗システム
売上集計
売上集信
売上データ
図 15
売上レポート
出力
プリントシステム
概要 DFD の例
61
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2007 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
NRI 技術創発
ように以下のステレオタイプ（モデル要素の
c 集約処理（ブレーク処理）の詳細化
種類）を追記する。
プロセスの詳細化が完了した DFD の中に
集約処理が含まれる場合、さらに集約処理の
¡ProcessingModel
詳細化を行う。
詳細化が完了した DFD 全体を示すモデル
FCI フレームワークでは、複数レベルのブ
要素。F C I フレームワークでは、この
レーク処理（複数のブレークキーを使った多
ProcessingModel がバッチアプリケーショ
段階の集約処理）から成る集約処理の設計を
ンの作成単位となる。
単純化するため、集約処理をレベルごとのブ
¡Source
レーク処理に分割して設計する方法をとって
入力処理を表すモデル要素。
いる。この方法に従って、集約処理の詳細化
¡Sink
を行う。
出力処理を表すモデル要素。
例を、図 18 に示す。この例では、売上集約
¡Matcher
処理（Aggregator）を、全体、地区、店の 3 つ
マッチング処理を表すモデル要素。
のレベルごとのブレーク処理に分割している。
¡Aggregator
レベルごとの集約処理を表すモデル要素を
集約処理（ブレーク処理）を表すモデル要素。
AggregateProcessor と呼ぶ。
ステレオタイプの追記が完了した DFD の
d 詳細化 DFD を元に設計、コーディング
例を図 17 に示す。
プロセスの詳細化、集約処理の詳細化が完
売上集計プロセス
入力処理
入力処理
売上データ
地区マスタ
集約処理
売上集約処理
マッチング処理
出力処理
地区名追加処理
地区別売上データ
マッチング処理
出力処理
店名追加処理
店別売上データ
入力処理
店マスタ
図 16
詳細 DFD の例
62
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2007 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
Java バッチ実用化に向けたフレームワークの開発
<<ProcessingModel>>
売上集計プロセス
<<Source>>
<<Source>>
売上データ
地区マスタ
MA Stream
<<Aggregator>>
TR Stream
売上集約処理
TR Stream
<<Source>>
<<Sink>>
地区名追加処理
地区別売上データ
<<Matcher>>
<<Sink>>
店名追加処理
店別売上データ
MA Stream
店マスタ
図 17
<<Matcher>>
ステレオタイプ追記 DFD の例
<<Aggregator>>
売上集約処理
<<Source>>
売上データ
<<AggregateProcessor>>
地区CD 店CD 売上CD
A
01
1
A
01
2
A
02
3
A
02
4
B
03
5
B
04
6
B
04
7
UriageAggregator::getAreaCount()
=>2
全体集計（地区のカウント）
<<AggregateProcessor>>
地区ごとの売上集計
<<AggregateProcessor>>
店ごとの売上集計
地区CD 店CD 売上CD
A
01
1
A
01
2
A
02
3
A
02
4
B
03
5
B
04
6
B
04
7
図 18
地区CD
売上
A
10
B
18
地区CD
売上
01
3
02
7
03
5
04
13
集約処理詳細化の例
63
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2007 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
NRI 技術創発
了した DFD をインプットに、バッチアプリ
ケーションの詳細設計、コーディングを行う。
現在、FCI フレームワークでは、以下の 2
つのフロー制御クラスを提供している。
詳細化が完了した DFD のモデル要素は、
FCI フレームワークを利用する上で作成すべ
¡SingleThreadFlowController
きクラスと 1 対 1 に対応している。つまり、
入力処理で読み込まれたデータごとに、シ
DFD の詳細化が完了した時点で、クラス分
ングルスレッドで後続の集約処理、マッチ
割（モジュール分割）までの設計が完了して
ング処理、出力処理を呼び出す方式のフロ
いることになる。
ー制御を行う。
引き続き、これらのクラスごとに詳細設計、
コーディングを行う。コーディング時には、
¡MultiThreadFlowController
これらのクラスごとに FCI フレームワークが
入力処理、集約処理、マッチング処理、出
提供するスーパークラスを継承し、業務ロジ
力処理のすべての処理をマルチスレッドで
ックを実装する。
実行しながらデータの受け渡しを行う方式
のフロー制御を行う。
フロー制御ロジックの抽入方法のコーディ
e フロー制御ロジックの注入
最後に、完成したバッチアプリケーション
ング例を図 19 に示す。
に対してフロー制御ロジックを注入する。
具体的には、バッチアプリケーションを表
（４）導入支援ドキュメントの整備
す ProcessingModel クラスのインスタンスを
Java 言語によるバッチ開発を現場へ導入
生成し、これを引数として適切なフロー制御
して生産性を向上させるためには、単にフレ
クラスの doTask（）メソッドを呼び出す。
ームワークを提供するだけでなくフレームワ
これにより、選択したフロー制御ロジックに
ークの導入を支援する各種ドキュメントを整
従ってバッチアプリケーションの実行が行わ
備し、提供する必要がある。
今回、筆者らは、性能検証プロジェクトの
れる。
シングルスレッドの場合
singleThreadFlowController.doTask( processingModel )
マルチスレッドの場合
multiThreadFlowController.doTask( processingModel )
図 19
フロー制御注入のコーディング例
64
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2007 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
Java バッチ実用化に向けたフレームワークの開発
中で RI フレームワーク、FCI フレームワーク
対象業務群から業務パターンを抽出し、業
を利用した Java バッチの開発を行った。こ
務パターンごとの DFD の雛型を示す DFD
の中で、フレームワークの適用を円滑に行う
マッピング標準化ガイドを利用した標準化
ための基本設計書の雛型（テンプレート）を
が有効であると考えられる。
作成した。
この標準化により、保守性が向上するとと
今後、以下のような標準化ドキュメント・
手順書を実プロジェクト適用の中で作成して
もにアプリケーション間のモジュールの共
有化が促進され生産性の向上も期待できる。
いく予定である。
¡Java バッチコーディング基準書
¡DFD 作成標準化ガイド
Java バッチのコーディングルールを規定
概要レベル DFD の記述方法を標準化する
するための基準書。今回、筆者らは、Java
ためのガイドラインドキュメント。FCI フ
バッチの性能向上を目指した RI フレーム
レームワークを利用した設計では、詳細レ
ワークを作成し、その効果を確認した。し
ベル DFD の作成基準は明確であり、設計
かし、フレームワーク側でいくら性能を向
者間のバラツキは少ない。一方で、概要レ
上させても、アプリケーション側で性能を
ベル DFD についてはゆるやかな基準しか
低下させるようなコーディングがあればそ
規定していないため、設計者によって異な
の意味がなくなる。よって、Java バッチコ
ったレベルの DFD を作成してしまう可能
ーディング基準書を用意し、性能を低下さ
性が高い。よって、概要レベル DFD の記述
せるようなコーディングを防ぐための取り
方法、記述レベルをプロジェクト内で標準
組みが必要である。
化するための DFD 作成標準化ガイドが必
また、コーディング基準書によるソースコ
要となる。
ードの可読性向上や保守性向上の効果も重
要である。
¡DFD マッピング標準化ガイド
業務パターンから DFD へのマッピングを
¡Java バッチ単体テスト手順書
標準化するためのガイドラインドキュメン
Java バッチの単体テスト方法を規定する
ト。DFD は自由度の高い記述方法である
ための手順書。FCI フレームワークを利用
ため、同一の業務処理を対象としても、分
したバッチアプリケーションの単体テスト
析者、設計者によってまったく異なったモ
工程においては、単体テストを行うモジュ
デルを作成してしまう場合がある。よって、
ールの単位やそのテスト方法を規定するた
65
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2007 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
NRI 技術創発
めの手順書が必要である。
５．様々な Java バッチ処理方式への対応
（１）J2SE バッチと J2EE バッチ
（５）最新の開発技術導入の可能性
最新の開発技術／ツールの多くは、Java 言
Java アプリケーションの実行環境には
J2SE 環境と J2EE 環境があり、各々の実行環
語によるアプリケーション開発をターゲット
境で動作する Java バッチを J2SE バッチ、
としたオープンソースプロジェクトから生み
J2EE バッチと呼ぶことにする。これら Java
出されている。特に、統合開発環境である
バッチの特徴を以下に示す。
Eclipse と、Eclipse を基盤として動作する
様々な開発支援ツールのプロジェクトでは、
¡J2SE バッチ
新たな開発技術への取り組みと導入が活発に
J2SE バッチは、OS 上のコマンドラインア
行われている。
プリケーションとして動作する。つまり、従
Java バッチの開発にこれらの開発技術／
来の COBOL バッチと同様に運用管理ツー
ツールを導入することによって、さらなる生
ルから起動し、管理することが可能である。
産性、品質の向上が期待できる。
よって、J2SE バッチは従来のバッチシス
今後、以下のような開発技術／ツールのフ
レームワークへの取り込みを予定している。
テムの一部に Java バッチを導入したり、
段階的に Java バッチに移行する場合に適
した手法である。
¡テスト自動化ツール
テスト自動化ツールとフレームワークを連
¡J2EE バッチ
携させ、単体テスト、連結テストの自動実
J2EE バッチは、J2EE アプリケーションサ
行や回帰テストを実現する。
ーバ上のアプリケーションとして動作する。
よって、オンラインアプリケーションから
¡AOP（アスペクト指向プログラミング）ツ
非同期に実行されるディレードオンライン
ール
処理や、まとまったデータに対してアプリ
デバッグ時のみ利用するデータダンプ機能
ケーション処理を一括実行するセンターカ
などを、本体のプログラムを変更せずに後
ット処理に適した手法である。
から追加できるようにする。
J2EE バッチは、オンラインアプリケーシ
ョンと共通の基盤を利用するため業務ロジ
ックや共通部品等の再利用を行いやすいと
いう特徴がある。
66
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2007 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
Java バッチ実用化に向けたフレームワークの開発
また、J2EE 基盤が提供するクラスタリン
形式等）の入出力機能を追加した。これによ
グ機能によりスケールアウト構成をとるこ
り、COBOL バッチと Java バッチとの間のデ
とで、性能の向上も期待できる。
ータ連携が容易に行えるようになる。
（３）J2EE バッチへの対応
（２）J2SE バッチへの対応
すでに述べたように、J2SE バッチは従来
J2EE 基盤はオンラインアプリケーション
のバッチシステムの一部に Java バッチを導
のために設計された基盤であるため、バッチ
入したり、段階的に Java バッチに移行する
アプリケーションのための実行制御機能を提
場合に利用される手法である。
供していない。よって、そのままでは J2EE
バッチを実現することができない。
よって、J2SE バッチは他のバッチプログラ
ムと混在した環境で動作する必要がある。そ
そこで、筆者らは、J2EE 基盤にバッチ実
こで、筆者らは、バッチプログラムとして広
行制御機能を付加するミドルウエアを開発し
く利用されている COBOL バッチと、Java バ
た。
（現在、オブジェクトワークス/BT JOB
ッチの連携をサポートする機能を開発した。
Manager として製品化）
本ミドルウエアの構成を図 20 に、各々の
具体的には、RI フレームワークに COBOL
機能を以下に示す。
特有のデータ型（符号付ゾーン形式やパック
非同期実行
ジョブ管理
キューイング
同時実行数の制御
アプリケーション
Job
Manager
リスナ
ジョブ管理TBL
Queue1
ジョブクラスA
Queue2
ジョブクラスB
Queue3
ジョブクラスC
実行制御ミドルウェア
ジョブイベント通知
図 20
J2EE バッチ実行制御機能
67
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2007 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
NRI 技術創発
¡ジョブの非同期実行機能
ョブの正常終了、ジョブの異常終了等があ
オンラインアプリケーションから、ジョブ
る。これにより、アプリケーション側でジ
の非同期実行要求を受け付ける。オンライ
ョブの状態変化をトリガーにした処理を実
ンアプリケーションに制御を戻し、バック
行することが可能となる。
グラウンドでジョブの実行を行う。
６．おわりに
¡ジョブ管理機能
現状では、オンラインアプリケーションを
ジョブの状態管理を行う。ジョブの状態に
Java 言語で開発していても、バッチアプリケ
は、実行待ち、実行中、正常終了、異常終
ーションは従来通り COBOL 言語で開発する
了等がある。また、オンラインアプリケー
という事例が多い。この主な理由は、Java バ
ションに対してジョブの状態を取得する機
ッチ（Java 言語によるバッチ処理）に対する
能を提供する。
性能面での不安が大きいためであると考えら
れる。一方で、生産性向上へのさらなる要求、
¡ジョブのキューイング機能
COBOL 技術者確保への不安、Java 実行環境
実行要求時に指定されたジョブキューに対
の性能向上を受けて Java バッチへの期待は
してジョブのキューイングを行う。ジョブ
高まりつつある。このような状況を受けて、
は、キューイングされた順に実行される。
筆者らは、Java バッチの実用化に向けた取り
また、ジョブキューの溢れ検知機能や、ジョ
組みを行った。
ブキューの閉塞・閉塞解除機能を提供する。
まず、Java バッチの性能向上を目指して、
オブジェクト生成とデータ変換処理を削減す
¡ジョブの同時実行数制御
る RI（Record Item）フレームワークを開発
ジョブの同時実行数をジョブキュー単位に
した。性能検証の結果、Java バッチの性能を
設定された最大値により制限する。これに
COBOL バッチと同等以上にまで引き上げら
より、ジョブキュー単位で CPU リソース
れることがわかった。
を配分することができる。
次に、Java バッチの生産性向上を目指し
て、設計モデルに DFD を採用し DFD の段階
¡ジョブイベント通知機能
的詳細化により設計を行う手法を採用した
ジョブイベント（ジョブの状態変化）をオ
FCI（Flow Control Injection）フレームワー
ンラインアプリケーションに通知する。ジ
クを開発した。
ョブイベントには、ジョブの実行開始、ジ
さらに、Java バッチの様々な処理方式に対
68
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2007 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
Java バッチ実用化に向けたフレームワークの開発
応するための取り組みを行った。この中で、
J2EE 基盤にバッチ実行制御機能を付加する
ミドルウエアを開発した。
これらの取り組みにより、Java バッチの実
●参考文献●
［1］近代科学社『ソフトウエアアーキテク
チャ』F.ブッシュマン他著金澤典子
他訳 2000 年刊
用化に対する目処を立てることができた。
一方、Java バッチの本格的普及に至るまで
にはいくつかの課題が残されている。例えば、
今回は典型的なアプリケーションを対象に性
能向上の取り組みを行ったが、今後は多様な
アプリケーションを対象に性能向上のための
ノウハウを蓄積していく必要がある。また、
今回開発したフレームワークを活用し、生産
性向上へと結びつけるためには、各種標準化
ドキュメント、手順書を整備する必要がある。
今後、実プロジェクトへの適用を重ねる中で、
これらの課題に対する取り組みを行っていく
予定である。
69
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2007 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.

Download Report