先ごろSpring Batch(リンク・英語)プロジェクトは、Springベースの軽量で包括的なバッチフレームワークの、バージョン1.0(リンク・英語)をリリースした。InfoQでは、このリリースの詳細と、それがSpringコミュニティにもたらすものについて、プロジェクトリードのDavid Syer(リンク・英語)に話を聞いた。
Syerは、Spring Batchについて、アプリケーション開発者がビジネスロジックにフォーカスするために、バッチとオフライン処理の問題を管理する、フレームワークのようなものだと述べた。Syerは、Spring Batchがバッチ処理の世界にもたらす、分離してテストできる、軽量なアプリケーションコードを書くための能力、そして、オフライン処理の実行および、結果の管理と監視のための、強力なフレームワークという、2つの新しいアイデアについて明らかにした。
Syerが明らかにした、このリリースの主要な機能は、以下のとおり。
- 基盤 - これは、繰り返しとリトライ、トランザクションの同期化、フラットファイル、XML、およびデータベースの読み込みと書き込みに対して、再利用可能な低レベルのサポートを提供する。
- コア - これは、バッチジョブの起動と管理を可能にし、操作上、必要となるすべての機能を提供する、薄いAPIだ。
- 実行 - これは、バッチ処理のためのランタイム・実行環境を提供する、コアAPIの実装だ。
- サンプルアプリケーションの包括的なセット - Spring Batch 1.0は、Spring Batchでの操作における、すべての主要な機能を明らかにする、いくつかのアプリケーションを含んだ、サンプルモジュールを提供する。
Syerはまた、バージョン1.0で利用できる(リンク・英語)、すべての機能についての、詳細な説明も行った。
Spring BatchがSpringポートフォリオのその他のプロジェクトと異なる点の一つは、Spring BatchがSpringSource(リンク・英語)とAccenture(リンク・英語)のパートナーシップの結果であるということだ。SyerはInfoQに、コードベースに対する貢献の、数と深さにおいて、パートナーシップは、大きな利益をもたらし、Accentureがプロジェクトに対して、最大限のリソースをアサインしたことで、パートナーシップは「大成功」したと述べた。Syerはまた、Spring Batchが、Springポートフォリオのすべてのプロジェクトのように、いくつかの作法と標準に従って実行されることを、注意深く指摘した。
Subversionリポジトリの日付によると、Spring Batchには、2007年1月からという、比較的、長い開発過程がある。Syerは、この理由を以下のように説明した。
もちろん、もう少し早くリリースできれば良かったのですが、実際には以前から、他のSpringポートフォリオがリリースされ、SpringSourceサブスクリプションプロジェクトが利用可能になる、2008年5月を予定していました。特に、今後の開発に対して、計画を変更する必要がないように、公開するAPIの設計は、とても慎重に行わなければなりません。全体的なプロダクトの品質も、大きな要因になります。私たちは、完璧主義なのです。
とはいえ、機能の成熟度と豊富さは、マイルストーンリリースを製品で利用した、少数のプロジェクトによって明らかになりました。
こうした製品プロジェクトのいくつかについて、さらなる詳細をたずねたところ、Syerは以下のように述べた。
- ヨーロッパの大規模なヘルスケアプロバイダでは、アプリケーションの全面的な再開発プロジェクトの一環として、メインフレームの多くのバッチ処理を、Spring Batchに移行しました。これは、かなりありふれたパターンで、今日の労働市場で利用できるスキルとして、優れたSpring開発者は探しやすいが、優れたCOBOLプログラマは、より探しづらいという事実に基づく要求です。このクライアントでは、オフライン処理の一部として、結果をある程度、再利用できるように、ビジネスオブジェクトを永続化するためのHibernateと一緒に、Spring BatchのXMLストリーミングとマッピングの機能を利用しました。
- 大規模なスポーツ団体では、ユーザがゲームの状況をリアルタイムに追跡するために、スコアと統計をライブで更新します。彼らは、迅速な開発を可能にするために、必要な設定だけを、ファイルから読み込むシステムを開発しました。モジュール方式のアプローチは、5秒ごとに起動される、ジョブの高速な実行も可能にしました。
- 大規模なアメリカの州政府では、ITの再開発プロジェクトとして、メインフレームのバッチジョブを、Javaに置き換えました。その目的は、失業手当の請求を処理することです。このチャレンジには、レガシーなメインフレームと政府特有のデータフォーマット、そして部分的なジョブの失敗に関する厳密なルールがありました。このケースでは、バッチジョブの開発は、前倒しされた非常に多くのプログラムの一部だけでした。
Syerはまた、アプリケーションの実装で陥りやすい、3つのカテゴリを挙げた。
- レポーティング、注文処理、アカウント調整などの、業務終了処理。
- 帳票処理、在庫のインポート、引当のエクスポートなどの、インポートおよびエクスポート処理。
- メールによるキャンペーンや財務諸表などの、大規模な出力を行うジョブ。
Spring Batchの将来の計画についてたずねたところ、Syerは以下のように述べた。
私達は1.0で、単一のプロセス(あるいは複数のスレッド)を実行するための、優れたプラットフォームを提供しました。将来的には、さまざまなプラットフォームで、大規模なマルチプロセスモデルに移行する可能性が高く、私達は1.0のコードベースの変更に対して、とても慎重に準備してきました。私達はまた、すでに必要なフックやデータ構造の多くを提供しているプラットフォームで構築する、バッチアプリケーションの使いやすさやデプロイのしやすさについても、とても真剣に考えています。現実の製品の状況において、バッチアプリケーションの監視と管理はとても重要なので、私達は、この領域にさらなる価値を加えることのできる、多くの方法を考えています。他のSpringポートフォリオのプロジェクトと同様に、私達はOSGiを、将来の戦略のための重要な一部であると考えています(1.0はOSGiバンドルとしてパッケージされていますが、それは本当に始まりにすぎません)。
Syerはまた、フォーラム、バグレポート、議論およびコードを通じて、Spring Batchに貢献したすべての人々に感謝し、フィードバックの品質と量の両方について「本当に素晴らしい」と述べた。
原文はこちらです：