久しぶりの勉強会エントリですが、GlassFish Users Group Japan 勉強会 2013 #1に参加して来ました。
勉強会の内容は、サブタイトルの「Java EE 7リリース記念・集中勉強会」の通り、先日リリースされたJava EE7の機能についての紹介がメインでした。個人的なJava EEとの関わりはほぼJBoss ASだったので、GlassFishには疎いのですが、そんなことは関係なく非常に参考になる勉強会でした。事前知識はGlassFish v4をインストールして起動しただけですw
すばらしい資料が公開されていますので、感想と備忘録だけ残します。
はじめに
会場のオラクルへは19時少し過ぎについたのですが、ほぼ満席でした。
Enterprise Editionだけあって、普段の勉強会よりも圧倒的にスーツの人が多かったですね(かくいう私もですが)。会社の身近にJava EEの有識者が少ないので、Java EEな人で溢れた空間は新鮮でしたw
JSR 352 Batch Applications for the Java Platformの話(@n_agetsuさん)
Java EE 7の新機能の中でも、業務的に特に関わりが深いと思われるので、どんなものなのか知ることができて収穫でした。
仕様自体も興味深かったし、また、これから更に改良されていきそうな予感もしました。
メモ
- jbatchはJP1やA-Autoなどのジョブスケジューラを置き換えるものではなく、補完的な役割を果たす。jbatch自体には(まだ)スケジューリングや実行権限の管理のような機能は仕様化されていない。
- FlowはJobをグループ化したもの。Jobは一つ以上のStepで構成される。Flow > Job > Step。
- Job(マスタデータ)からスケジュールごとのJobInstance、さらに実行ごとのJobExecusionが作られる。何月何日の何回目の実行、というのがそれぞれ別インスタンスとしてきちんと区別される。
- Stepの実行方式はChunkとBatchletの2つ。
- jbatchが依存するのはCDI、JTAのみ。Java SEの上でも動作させることは可能(オススメはやはりJava EEとのこと)。
- ジョブの定義はXMLで書く。そのうち、使いやすいIDEサポートとか、Builderパターン的にJavaコードで定義できるとかが出てくる(かも)?
感想
- Spring Batchははじめて知りました。ファイル連携、JPA連携、極力Java EEに依存しない作り、と良さそうな匂いだったので、jbatchと併せて少し調べてみたいと思います。
- Flowがジョブスケジューラで言うところのジョブネット?階層構造はできるのかな…。
- JobとJobInstance, JobExecusionを区別する考え方(単語はともかく)はジョブスケジューラだと一般的なのかなと認識してます。
- ジョブスケジューラのジョブの実行方式は、すべてBatchlet方式に該当しているのかなと思ってます。なので、Chunkみたいにある程度のまとまりで実行する、みたいなものは新しく感じました。うまい使い道を検討してみたいです。
- JAX-RSが身の回りで割と浸透している(?)のを見ると、Java SEでも気軽に試せるのは重要な成功要因の気がします。
- 大量のJob、Decision(分岐)、Split(並行実行)が組み合わさった高度な処理を記述するのは、かつてのbuild.xml hellのように、XMLではキツいと思うので、これからいいサポートツールが出てくることに期待したいです。
HeapStats(@sugarlifeさん)
OSSの障害解析支援&監視ツールの話。実際に使ってみて、イメージをつかみたいと思いました。
Thin Server Architecture(@makingさん)
ビジネスロジックはサーバ側(バックエンド)が担当し、サーバはREST APIを公開する。クライアント側(フロントエンド)はREST API経由で、主に画面描画を担当する。みたいな最近ポピュラー(?)なアーキテクチャの話です。クライアントの実装の選択肢としては、クライアントMVC(Backbone.js等)やJava FX、Ruby on RailsならActiveResourceを使うとか色んな方法がありますが、JSFでやってみたよという話でした。
趣味の範囲ではPlay Frameworkでやってみようかなと思っていたところだったので、タイムリーでした。
シンプルできれいな構成ですよね。会社で関わる業務アプリケーションの標準アーキテクチャにしたいくらいです。
今晩から始める Java EE 7(@btnrougeさん)
質疑応答でやはり(?)JAX-RS 2.0の話が盛り上がりましたね。
jbatch, WebSocket, JAX-RS 2.0は週末に試してみようと思います。
JAX-RSのところのエラー処理で私が使っているのは、アプリケーションのロジックが投げる例外はAppExceptionみたいな基底の例外クラスとそのサブクラス例外にしておいて、AppExceptionのExceptionMapperだけを定義する方法ですね。例外ごとにExceptionMapperを作るのは面倒なので。あと、レスポンスボディにExceptionのgetMessage()の内容をそのまま突っ込んでた気がします…。
クライアントはJersey Client APIで十分な気もするので、乗り換えはしないかもしれないですね。