駄め犬の遠吠え: jjugナイトセミナー

2016/02/15

jjugナイトセミナー

ラベル: CDI, EJB, Java, JavaEE, jBatch, jjug, JSF, 勉強会

jjugナイトセミナー

#

JSF

Java EE5 から導入されたプレゼンテーション層を作成するためのFW
Java EE7でのバージョンはJSF2.2
過去はサーブレット＋JSPだったため、高レイア機能がなく、サードパーティ製のFWを合わせて使っていた。

→ これを標準で提供しよう！というもの。

フェースレット

画面のレイアウトを記述するXHTMLベースのテンプレートエンジン
→ JSF2.0からフェースレットに置き換わった。（もともとJSP）
JSPとの違い

厳密（XML）
スクリプレットが記載できない。

処理が書けない。

文字列のサニタイジング

標準tag lib的な？

フェースレットの構成要素

タグリブ

h:XXXXのタグライブラリ

EL

#{XXXXX}で記載する。メソッドを読んだり、変数を表示したり。

マネージドビーン

フェースレットとバインドするjavaのクラス

フェースレット＝View, マネージドビーン＝ViewModel

構成要素

スコープ

アノテーションで定義

バインドする値の保持
バインドするメソッド
などなど

フェースレットのフォームなどとマネージドビーンをEL式で紐付ける。

本書では触れられなかった話

JSFのより詳細な機能

カスタムコンポーネント

タグライブラリの拡張

イベントハンドリング

Value Change Events

値を変更してボタンを押してから動くイベントの機能なので今時は使わない。

Action Events

ビーンバリデーション

グループ化機能

登録画面と変更画面で微妙に変えたい！とかに使うらしい。

EL

Lamda式が使える話
文字列連結オペレータ

Java EE 8 (JSF2.3)

WebSocket対応
マルチフィールドバリデーション

複数フィールド間のチェックが現状でないため、これの対応

Java Timeサポート
EL式で利用可能な暗黙オブジェクトの追加
マネージトビーン等への@Inject可能なオブジェクトの追加

MVC1.0

アクション指向フレームワーク
Java EE 8で導入（現在ドラフト）
JAX-RSを拡張
ビューにはFaceless,JSPをサポート

画面のコンポーネントなどの提供は現状なし

名前が直接的だけど紛らわしい。

JSF関連ライブラリ

コンポーネント系

画面をリッチに構築するライブラリ

グラフとかアコーディオンとか。。。
PrimeFaces

JSFを利用したリッチなUIフレームワーク

ライブラリ系

JSFの開発を容易にするライブラリ

今後のプレゼンテーションの選択肢

JSF
JAX-RS(REST FW) + クライアントサイドフレームワーク(JavaScript)
MVC1.0 + Web Components?

まとめ

プレゼンテーション層の開発について

Java EE 7環境でのプレゼンテーション層の選択肢

サーバサイドでJava開発＝JSF
クライアントサイドでJavaScript開発＝クライアントサイドフレームワーク＋JAX-RS

# ビジネスロジック層の開発 CDI & EJB

CDIとEJBは排他的な関係ではない。

実際は組み合わせて使っていくのが良いと思っている。

書いてないことを中心に話していくよ！
書いていること。

CDIの使い方
EJBの使い方

この先EJBってまだ使っていいんだよね？的な話を聞かれるが使い方があると思われる。

書いていないこと。

CDIコンテナの取り扱い
@ConversationScoped
トランザクションの取り扱い

おさらい。

CDIとは

DIの一種
ライフサイクルに沿ったDIをしてくれるもののことを指しそう。

スコープ定義

POJOにスコープ定義さえあれば、@Injectで好きな箇所でインジェンクションできる。

@RequestScoped

GETリクエストで返したら消える

@ViewScoped

タブが違うと違うものらしい。

@SessionScoped

セッションにひもづく

@ApplicationScoped

アプリがデプロイされてから死ぬまで

@ConversationScoped

ライフサイクルをカスタマイズできるっぽい

EJBと比較するとリソースメリットがある

EJBだとプールがある（？）のでなかなかオブジェクトが消えないが、CDIだと使って終わったらすぐ消えるため軽いはず

CDIコンテナの取り扱い

Weldが実装らしい。
Weldのバージョンを気にした方がいいと思う！

開発環境と商用環境のAPサーバのWeldのバージョン差異のため動かないことがあるよ

細かい話はついていけなかった。。。
@ConversationScoped

自分でスコープ長を定義できる
begin() → end()やタイムアウトで指定
JSFとは勝手にひもづけられる。。。。

トランザクションの取り扱い

書かなかった言い訳が思いつかない。。。
JTA1.2(JSR-907)
めざせEJB CMTからの脱却
みんなそんなにEJBが嫌いなのか！
java.transactionパッケージ

@Transactional

トランザクション境界の設定
クラス・メソッドどちらでも
JTAなのでCDIビーンじゃなくても使える。

@TransactionScoped

現在有効なJTAトランザクションの実行に合わせたライフサイクルを持つもの

まとめ

EJBは時代的にアレだがCDIで何でもかんでもって設計もどうかなって思う。

密結合させることも必要だし悪くない。
スコープ制御しきれない実感
EJBみたいにプールが欲しい時がある。

EJBに任せてもいい処理があるのでは。

最近こう思ってる。

CDIが本格的に進出してきたことでフリーダムになってしまった印象。
CDI+EJBでいいよね？

結構増えてきている。
各機能を限定して実装しているのがいいのでは？

この領域の残念なこと

フリーダム
アンチパターンが多くない（ので集めたい）

使いすぎよくない程度

本編で少し触れてるが、多量のインジェクションはやめましょう。

２回ほど見かけたが、Oracle Weblogic Serverが死にかけていた。
大規模開発現場で設計者が意図しないインジェクション数
かといってフレームワークで制御ってのも
設計でカバー？？

感想など

かけてないことがたくさんあった。
ちょくちょくどこかで発表したい。
楽しかった。

# バッチアプリケーションの開発 jBatch

What is “jBatch” / Why “jBatch”
jBatchの構成要素
本書に書いていないこと。
What is “jBatch”

バッチ処理の標準
Version 1.0 として Java EE 7 から登場
JSR-352で規定
Spring Batchから多くを継承

Why “jBatch”

プロセスとして実行

○ シンプル
▲ JVM起動時間のオーバーヘットがかかる
▲ APサーバで動く他の部品との共有が難しい

自作スレッドとして実行

○ スレッドはプロセスに比べて軽く起動できる
▲ スレッドを管理するmainプログラムを自作する必要がある。
▲ APサーバで動く他の部品との共有が難しい

サーブレットして実行

○ スレッドはプロセスに比べて軽く起動できる。
○ スレッド管理プログラムを自作する必要がない。
○ APサーバの部品との共有が容易
▲ 実行状況の把握、スレッドの停止が難しい。
▲ HTTPリクエストタイムアウトの問題

jBatchを利用

○ スレッドはプロセスに比べて軽く起動できる。
○ スレッド管理プログラムを自作する必要がない。
○ APサーバの部品との共有が容易
○ 実行状況の把握、スレッドの停止は機能がある。

jBatchの構成要素：”ジョブ”と”ステップ”

”ジョブ”は”ステップ”の入れ物
各ステップの名前や実行順序を定義する。→ ジョブ
実際の処理が描かれている。→ ステップ
ジョブ

ジョブ＝XML
ジョブ名はファイル名
ステップを切ってクラスのフルパスを入れる。

ステップ

jBatchのインタフェースに沿って実装をする。

ジョブとステップの分離

ジョブとステップの分離は、古くはホスト時代にさかのぼる。
jBatchは、時代や言語を問わずに共通する、バッチ処理の「ひな型」を提供する。

構成要素と機能

ジョブ

フロー

stepのまとまり

スプリット

分散処理用

デシジョン

分岐？

遷移要素

next
stop
end
fail

ジョブオペレータ

ジョブの操作。かいし・中断・再開
ジョブオペレータの呼び出し方法の規定がない。

JSFで画面を作る
JAX-RSでREST制御など

エラーハンドリング

リトライ
スキップ

※XDSを定義すると楽だよ

ステップ

チャンク型

複数データの一括処理

データを読んで加工して書き込むなどの一括処理

読み込み・加工を１０回繰り返した後に、一気に書き込むというフローがデフォルトで定義されている？

バッチレット型

データに依存しない処理や、コマンド発行

FTP転送とかフォルダ作るとか

補助機能

ジョブリポジトリ

ジョブやステップの情報を格納
通常はAPサーバ配下にある内部DBが実態

リスナ

処理の前後でイベントが発生
→r砂を付与して任意の処理を差し込む

コンテキスト

jobContextとStepContextの２種類
プロパティやステータスなど、実行中のジョブ・ステップに関する情報をAPI経由で提供
UserDataとして、ジョブ・ステップに横断的な人にの値をセットすることもできる

メトリック

ステップに関する統計情報
StepContext#getMetric()

書いてない話

ステップ・パーティショニング

ステップを任意のスレッド数で並行して処理する機能

なぜ入出力ファイルをCSV形式にしたのか？

JSONやXML形式の場合は、途中で中断した場合、閉じタグがないのでこける。

ここが変だよjBatch

チャンクのジェネリクスが使えない！
終了ステータス・バッチステータスがジョブとステップで共用なのが直感的じゃない。
flow/split単位でのpropertyが指定できない。
GFの参照実装だと。。。

とりあえず、メモの投稿。

そのうち綺麗にするかも。

駄め犬の遠吠え