Spring Batch m4

SpringSource Team Blog に Spring Batch の今後についての記事が掲載されました

http://blog.springsource.com/main/2008/02/04/spring-batch-recent-changes-and-upcoming-m4-release/

  • 1.0.0は3月20日あたりに出す?
  • Bean定義ファイルは名前空間を使って独自のジョブ定義っぽくなる(まさにJCL的)

あとで読んで見よう…

TERASOLUNA Batch Framework for Java

久しぶりの更新になります。

http://opentechpress.jp/opensource/08/01/29/1033205.shtml

まだかなーと思っていたらついに公開されました。
Spring FrameworkをベースにしたJavaバッチフレームワーク。
さっそくドキュメントをざっと拝見しましたが、現状の正式リリースに漕ぎ着けていない本家(Spring Batch)と比較して、その完成度は余裕勝ちじゃないでしょうか。
(私見ですけど。また、思想というか出発点がそれぞれ違うため、単純に比べることはできないという面もあります)
さすがというべきかチュートリアルなどもよく整備されています。

同じくSpring Frameworkを基盤としたJavaバッチフレームワークとして今後どうしてもSpring Batchと比較検討されることになると思いますが、バッチ処理のフレームワーク化という1つのアプローチの例としても貴重だと思いました。

9/7(金) JSUGでしゃべります

Spring Batchについて、日本SpringFrameworkユーザーグループの9/7(金)勉強会で、お話する機会をいただくことになりました。

http://springframework.jp/index.php?%CA%D9%B6%AF%B2%F1#abf5c59b

それなりに有益な時間を提供できるようにゆるゆると資料をつくっています。
クイックにSpring Batchについて把握したいという方はどうぞお越し下さい。

Spring Batch M2リリース

更新が遅くなってしまいましたが，Spring Batch の M2がリリースされています．

公開SVNリポジトリーはこちら

https://springframework.svn.sourceforge.net/svnroot/springframework/spring-batch/trunk/

ぼちぼち時間をとって，中身を追っかけていきたいと思います…

Chapter 5 バッチアーキテクチャーのための一般的な原則とガイドライン

Spring Batch

第4章はボリュームがあるので先に短い5章を。

      • -

以下は、バッチソリューションを構築する上で考慮すべきいくつかの鍵となる原則・ガイドライン・一般的な検討課題である。

  • バッチアーキテクチャは、概してオンラインアーキテクチャに影響を及ぼす(逆もまた真である)。可能であれば共通のビルディングブロックを利用することを念頭におき両方のアーキテクチャと環境を設計せよ
  • 単一のバッチアプリケーションにおいては可能な限り単純化し、複雑な論理構造を作りこんでしまうことを避けよ
  • 可能な限りデータがある場所に物理的に近いところで処理せよ(逆もまた真である)。(例：処理が発生するところにデータを保持せよ)。
  • システム資源の利用を最小化せよ(特にI/O)。可能な限り内部メモリ上で多くの処理を実行せよ
  • 不必要な物理I/Oの発生が確実に回避されるようにアプリケーションのI/Oを精査せよ(SQL文を分析するなど)。特に、以下の4つの良くある欠陥がないか検証を行うべきである
  • 毎回トランザクションでデータを読み込んでいる。データが一度読み取られるときにはキャッシュするかワーキングストレージに保持し続けられるようにせよ。
  • データが同一のトランザクションにおいて以前に読み込まれているなら、トランザクションでデータを再読み込みする。
  • 不必要なテーブルまたはインデックススキャンを引き起こしている
  • SQL文のWHERE節でデータを特定するキーとなる値を指定していない
  • バッチ実行時に2回同じ処理を実行しないこと。たとえば、レポート用にデータをサマリする必要があった場合、データが前に処理されていて利用可能なら保存している合計数を増加するようにし、そのレポートアプリケーションが同一のデータを再生成することがないようにせよ。
  • 処理中にメモリ再配置のための時間を浪費することを避けるために、バッチアプリケーションの開始時点で十分なメモリを割り当てよ
  • データの整合性(完全性)については最悪の状態を常に想定せよ。データの完全性を維持するためには適切なチェックとレコードの妥当性検証処理を盛り込むようにせよ
  • 可能な箇所に内部的な妥当性検証用のチェックサムを実装せよ。たとえば、フラットファイルではファイルにおける合計レコード数とキーフィールドの集約を保持するトレーラーレコードを持つようにせよ
  • 本番環境に近しい環境で、実データ量をもとにして可能な限り早期にストレステストを実施せよ
  • 大規模バッチシステムでのバックアップはチャレンジングである(特にシステムが24時間7日稼動のオンラインと合わせて同時並行的に実行されるようなシステムであるときは)。データベースのバックアップは、オンライン設計においては注意深く検討されるものだが、ファイルバックアップについても同様に重要であるものと認識した上で検討されなければならない。システムがフラットファイルに依存している場合、ファイルバックアップ手順は検討されドキュメントされるだけでなく、同じように適切にテストされねばならない。