Java EE 7 jBatchの使い方──『Java EE 7徹底入門』番外編 第3回

Oracle Java & Developers編集部
2016-04-04 11:00:00
  • このエントリーをはてなブックマークに追加

Java EE 7で新たに導入された待望のバッチ処理機能「jBatch」。その基礎、使用に際しての注意点を『Java EE 7徹底入門』の著者が解説する。

  • 第1回(プレゼンテーション層)の記事はこちら
  • 第2回(CDI)の記事はこちら

Java EE 7徹底入門(発行:翔泳社)

 本企画では、日本Javaユーザーグループ(JJUG)が2016年2月に開催した「JJUGナイトセミナー ─『Java EE 7徹底入門』の著者が解説!-Java EE 7特集」の内容を基に、『Java EE 7徹底入門 標準Javaフレームワークによる高信頼性Webシステムの構築』(翔泳社刊)の著者としてセミナーで講師を務めた日本オラクルのスペシャリストらによるJava EE 7の初級者向け解説をお届けしている。最終回となる今回は、日本オラクル クラウド・テクノロジーコンサルティング統括本部の猪瀬淳氏が、Java EE 7で新たに追加された「jBatch(Batch Applications for the Java Platform)」について解説する。


※クリックすると拡大画像が見られます

Java EEアプリケーションでjBatchを使うべき理由


日本オラクル クラウド・テクノロジーコンサルティング統括本部の猪瀬淳氏

 本記事では、jBatchの概要とJava EEアプリケーションの開発でjBatchを使うべき理由、そしてjBatchの構成要素と機能概要を説明するとともに、『Java EE 7徹底入門』に書き切れなかったjBatchに関する補足を行いたいと思います。

 jBatchは、Java EE 7で初めて導入されたバッチ処理の標準仕様であり、その詳細はJSR-352(Batch Applications for Java Platform)で規定されています。近年のJava EEでは、オープンソース・ソフトウェアの成果を標準技術として積極的に取り込んでいますが、jBatchでも、基本的な仕組みの多くを「Spring Batch」から継承しています。jBatchは、あくまでもバッチ処理の基本部分を標準化したものであり、Spring Batchのほうが機能は豊富ですが、jBatchに準じたバッチ・アプリケーションを作ることで、Java EEに準拠した環境ならどこでも動かせるというメリットがあります。

 現状、Java EEでバッチ・アプリケーションを作る方法は、jBatchを含めて大きく4つあります。


※クリックすると拡大画像が見られます

 1つ目は、バッチを個々のプロセスとして実行する方法です。そのメリットとしては、起動/停止や実行状況の把握などが直感的に行えて、全体的にシンプルに扱えるという点が挙げられます。

 その一方で、懸念点として、バッチを実行する度にJVMを起動するため、起動時間などのオーバーヘッドが発生することがあります。一般にバッチは実行時間が長いため、これが問題になることは少ないと思いますが、CPUなどのリソース面で不利になる可能性もあり、好ましくないと判断されるケースもあるでしょう。

 また、もう1つの問題点として、この方法ではアプリケーション・サーバ上で動く他の部品の共有が難しいということがあります。不可能ではないのですが、CDI(Contexts and Dependency Injection)、EJB(Enterprise JavaBeans)、JPA(Java Persistence API)といったJava EEの機能を使うためには別途ライブラリを追加する必要があり、簡単とは言えません。

 2つ目の方法は、バッチを自作スレッドとして実行するというものです。スレッドを管理するメインのプログラムを作り、各バッチをスレッドとして処理するのです。スレッドはプロセスよりも軽く起動できるため、1つ目の方法と比べるとオーバーヘッドは小さくなります。ただし、スレッド管理のためのプログラムを自作しなければならず、その分だけ敷居は高まります。また、この方法でもアプリケーション・サーバに備わるJava EEの機能を利用するのは難しいままです。


※クリックすると拡大画像が見られます

 3つ目の方法は、バッチをサーブレットとして実行するというものです。2つ目の方法のメインプログラムに当たる部分をサーブレットとして作るわけです。この方法では管理プログラムの自作が不要であり、Java EEの他の部品の共有も容易なため、一見すると良さそうに思えますが、実はそうでもありません。なぜなら、サーブレットから各バッチのスレッドを動かした場合、それぞれの実行状況を把握したり、処理に問題が生じたスレッドを個別に停止したりするのが難しいからです。また通常、バッチ処理が完了するまでには長い時間がかかりますが、その間にHTTPリクエストがタイムアウトしてしまう可能性もあります。

 以上に紹介した3つの方法が抱える問題点を解消する4つ目の方法がjBatchです。jBatchによるバッチ処理は、ジョブとしてスレッドの単位で実行されます。Java EEの仕様で規定されているため、個別にメインの管理プログラムを自作するなど、他のJava EE部品を共有するために特別な手段を採る必要はありません。

 加えて、実行状況の確認方法やジョブの起動/停止などの方法も標準化されています。jBatchを使ったアプリケーションであれば、Java EE標準の上で、より効率的にバッチを動せるようになるわけです。


※クリックすると拡大画像が見られます

jBatchで最初に理解すべきは「ジョブ」と「ステップ」

 次に、jBatchの具体的な使い方を見ていきましょう。まず、jBatchの構成要素には「ジョブ」と「ステップ」の2つがあることを覚えてください。


※クリックすると拡大画像が見られます

 上図に示したように、ジョブはステップの“入れ物”です。XML(Job XML)で記述され、その中には実行するステップの名前や順序、設定などが書かれます。バッチ処理の本体となるのはステップであり、ここに具体的な処理の内容をJavaで記述します。

 ジョブとステップの関係について、もう少し詳しく表したものが下図となります。


※クリックすると拡大画像が見られます

 Job XMLの最上位の要素はjobであり、これは属性idを持ちますが、実際のジョブ名として扱われるのはファイル名(上図の場合は属性idの値と同じSampleJob)です。また、要素propertyで各種の設定を行い、要素step内で処理内容を実装したJavaクラスを参照します。

 バッチにおいて、ジョブ(処理の固まり)とステップ(段階的に実行される個別の処理)を分離するという考え方は、特に目新しいものではありません。jBatchは、時代や言語の違いを超えて共通するバッチ処理の雛型を標準化したものだと言えます。