ぱと隊長日誌

ブログ運用もエンジニアとしての生き方も模索中

GlassFish Users Group Japan 勉強会 2013 #1 レポート

勉強会/セミナー Java

はじめに

GlassFish Users Group Japan 勉強会 2013 #1のレポートを公開します。
GlassFish Users Group Japan 勉強会 2013 #1 : ATND

色々調べてから公開したかったので、遅くなってしまいました。。

以下、注意点。
スライド資料に無い説明を中心にまとめているため、発表によってはレポートがすごく短いです。ぜひスライド資料をご覧ください。
【参考】としている個所は私が挿入しています（補足や参考資料など）。発表者の意図したものではありませんので、その旨ご了承ください。

Java EE 7から加わるバッチ仕様(@)

バッチってなんだろう？

正式な仕様名は『Batch Application for the java Platform』だが、これは公式にjbatchと略されている。

jbatchの概要

jbatchは開発者の実装をサポートするという思想で設計された。
そのため、仕様にAPIや例外制御が含まれている。
逆に、標準仕様ではジョブスケジューリングを含めていない。

jbatchはCDIとJTAに依存している。
逆に言えば、この2つだけに依存している。

jbatchがJava EEに含められたメリットとして、EJBやServletと連携できることが挙げられる。

アーキテクチャ

ジョブはリスタート可能/不可の設定だけでなく、ジョブID毎に一度だけ実行するという指定もできる。

JobInstanceは一つだが、JobExecutionは実行の度に生成される。
ジョブを再実行するとJobInstanceは再利用され、JobExecutionだけ生成される。
【参考】
この設計思想（理由）について調べてみたのですが、はっきりとはわかりませんでした。ただ、Spring Batchでも同様の設計になっており、そちらから調べてみると、
・JobInstanceはジョブ毎の実行条件を保持する
・JobExecutionはジョブの処理状態や結果を保持する
という役割分担をしているようです。ジョブの再実行であれば実行条件は変わらないためJobInstanceを再利用する。そして、処理状態や結果は実行毎に保持する必要があるのでJobExecutionを生成するようです。
※間違いがあればご指摘をお願いします！

『chunk方式の登場人物』スライドの説明
黄色枠はユーザーが実装する部分。以下の通り。
・ItemReader
・ItemProcessor
・ItemWriter

ItemReader#close()はリソースを閉じる処理を書く。

ItemReaderの実装クラスには@Namedを忘れずに。
これを忘れると見つけてくれないことがある。
【参考】

全てのコンポーネントに、@java.inject.Namedが必要。
ジョブXMLからコンポーネント名を指定するため。

ItemWriterは何かを書き出す処理を実装する。

chunk処理は直ぐに書き出さないのが特徴。
デフォルトは10回、読み込みと処理を繰り返す。
10アイテム溜まってから書き出しを行う。

初回実行時に引数checkPointはnull。リスタートする場合に値がセットされている。
リスタート処理は必要ないなら実装しなくてよい。
jbatchはチェックポイントを作りやすい仕組みを提供しているだけで、自動的に実現してくれるものではない。

ItemReaderで読みだすデータがなくなったら、nullを返す必要がある。
そうすることで書き出し処理が実行される。

コミット間隔を調整することでパフォーマンスの調整ができる。

ここで一言コメント。
jbatchはSpring Batchと非常に良く似ている。属性で定義するか、タグで定義するかという程度の違いしかない。

@ReadItemはjbatchにもspringにも用意されていない。jbatchのPublic Review版には存在したが、アノテーションだと何が必須メソッドがわからないという意見があり、finalでは見送りになった。

Spring Batchのtaskletがjbatchのbatchletに相当する。

Spring Batchとjbatch

基本的な作りは同じ。

jbatchは最低限のアーキテクチャのみ実装した。

jbatchのExpert GroupにはSpringSourceの親会社のVMWareもいる。
ということはSpring Batchがjbatch実装になる可能性も！？

Java Batch 動作環境

jbatchはJDK7でも8でも動いた。

JavaSEよりJavaEEで使うことをお勧めする理由。
・スレッドプールにJava EE 7のConcurrencyを活用している。
・Java EEの方が必要な設定ファイルが少ない。

もっとjbatchを知る

仕様書よりチュートリアルを見るのがオススメ。

Spring Batch IN ACTIONは参考になる。違いはちょっとだけ。

Spring Batch in Action

Spring Batch in Action

  • 作者: Arnaud Cogoluegnes,Thierry Templier,Gary Gregory,Olivier Bazoud
  • 出版社/メーカー: Manning Pubns Co
  • 発売日: 2011/10/07
  • メディア: ペーパーバック
  • この商品を含むブログを見る

サンプルアプリはItemReaderでツイートを取得し、WriterでDBに書き込み、次のステップでDBからデータを取得して解析している。

GlassFish4はNetBeansと組み合わせるのがオススメ。
ボタン一発で起動できる。

QA

Q.
ジョブXMLを書かずにコードで書けないの？
A.
同様の意見は出ていてチケットも上がっている。もしかすると次のバージョンで対応されるかも？
また、XMLを生で書くのは厳しいのでIDEでサポートする方向になっていきそう。

HeapStats で GlassFish 4 障害解析(@)

HeapStatsはGCと同期して情報収集しているが、これはJRockitでも同様。

JSFとJAX-RSで作る Thin Server Architecture(@)

JavaScriptではなくJSFで書きたい！
でもJSFはRESTが使えない…。
このジレンマをクライアントAPIを使うことで解消した。

Java EE 7 overview(@)

http://www.slideshare.net/btnrouge/java-ee-7-overview

Features

Java EE 7はJava EE 6をベースに進化させている。

マイナーアップデートについて。
マイナーといえど、JSRを新たに作るほど機能追加に力を入れている。

マイクロアップデートについて。
資料中の"<"は影響を受けて修正されたことを示している。

Java EE 6でPruningと予告されていたものが実施された。

GlassFish 4は基本的にGlassFish 3のアーキテクチャを踏襲している。
GlassFish 3より早くなっている。
CDI系のバグはGlassFish 4で大分解消した。（発表時点で）まだあるけど。

Examples

JAX-RS 2.0

1.1ではWebApplicationExceptionだけだった。これがStatusに応じて細分化された。

サーバーとクライアントで同じ例外がthrowされる。
間にHTTP通信などを挟んでいることを意識しなくて済む。

Bean Validation 1.1

Method validation
メソッドの引数にBean Validationを使える。スライドの例だと@NotNull。

Group conversion
入れ子のグループを扱いやすくする。

QA

Q.
GlassFish 3ベースということだが、GlassFish 4は商用にすぐ使える？
A.
GlassFish 4は最初からフル機能になっている。
ただ、バグがまだ多い。バグは4.0.1で大分解消される。ただし、（発表時点で）リリース時期はまだ未定。

リンク集

@さんによるtweetまとめ
GlassFish Users Group Japan 勉強会 2013-Vol.1 #glassfishjp - Togetter
GlassFish
GlassFish
HeapStats
HeapStats - IcedTea

更新情報

2013/07/17:
・『Spring Batch IN ACTION』のリンクを追加しました
・リンク集にGlassFishとHeapStatsのリンクを追加しました