JBoss 勉強会 1st at Tokyo
JBoss 勉強会 1st at Tokyo
というわけで、勉強会と言われる類のものをここ数年拒否*1
していたのですが、JBossSeamに導かれてでてしまったのでしたよ。
レジュメは以下の通り、
■ JBossデータソース
JBossのデータソースがどのような動きをするか内部的な構造を追いながらの解説。深い。深い。
おそらく効用としてはトラブルの際のリカバーやデフォルト動作に不満がある場合の変更方法でが主なものだろう。
と言いつつ、おそらくこういった内部構造の精査は実のところ楽しいからやってしまうと側面がなくもないなという感じか。
○キーワード
■ JBossサイトの歩き方
JIRAやFishEyeの利用方法の解説。そしてメイン・トピックはJBossCertifiedコンサルタントの資格をいかにして取るか（笑）
日本でJBossコンサルタントのトレーニングを行うのにはもう少し時間がかかることを認識。
○キーワード
- 企業プロダクトでは当然な影響範囲調査を行わずさくっと直してしまうところ。そういったところに脇の甘さがあるのでは。
（キーワードじゃないね！）
- 最近のソースツリーがぐちゃぐちゃ。
- ちなみにJIRAは日本語化されて18万，50万，72万の3バージョンがある模様。
■ JBoss Seamの紹介
さて、お待ちかねのJBossSeamの登場で、わくわくという感じ。
セッションの内容はWiki中のスライドを見ていただくこととして、
はっし〜〜の私見を以下述べさせていただく。
以前からSeamを見て思うのがRailsを非常に意識している点だ。
本日、オカモト君と話していたときに
JBoss Seam FAQ のことを教えてくれた。
http://labs.jboss.com/portal/jbossseam/faq
には以下のようにRailsに対して少々意識した内容が書かれている。
Q： Does Seam have something like the Ruby on Rails "flash" object?
→ Rails の flash*2 って Seam にはあるの？
A ： No, Seam has something much more powerful: a conversation context. The Seam conversation context is propagated across redirects (even when no long-running conversation is in progress), so you can use the conversation context to store success messages and the like.
→ いんや、Seamには conversation コンテキストというもっとパワフルなものがありますぜい。
conversation コンテキストは、（たとえ、ロングランでのconversationが途中でなくてもでも）リダイレクト前後で伝搬されちゃうのだ（生き残る）。
なので、成功を表現するメッセージやそういった類なものを保持するためにconversation コンテキストは使えまっせ
-
- -
とまぁ、Railsよりもリッチだぜということも言っている。
それから、Railsが今後の方向性としてRuby会議でDHHがRESTライクに行くかもという話だったが
・ http://www.loudthinking.com/lt-files/worldofresources.pdf
Seamも負けじと実装する（した？）ような話を聞く。
・・・・となかなか火花を散らしているなぁという感じ。
○ フルスタック
当たり前なことだが、RailsはWebアプリケーションにおける MVC モデルに対してすべての層に対応するフルスタックのフレームワークを提供している。
同様にSeamもJavaでは数少ないフルスタックのフレームワークの提供をしている*3。
○ View
Seamで利用が想定される、JSF ＋ Facelet と
RailsのActionViewがすごくよく似ているなという感じ。
当初、JSFとActionViewの違いがSeamとRailsの違いかなと思っていたが、とんでもない。
Facelet をかませた JSF は Rails の ActionView とよく似ている。
ただ、JSFの場合はXML(JSF)タグを利用する一方で、RailsはERBのテンプレートのなかでヘルパーメソッドを利用するという違いがあるのだが、
ここら辺の実例は気が向いたら紹介しようと思う。
○ Exposed Domain Model
RailsとSeamで似ていると思ったのがいわゆる
Exposed Domain Model（無防備なドメインモデル）で、DTOを利用しないというところかな。
この点、Seasarコミュニティの方々を初めてとして賛否両論があったりする*4。
なお、Exposed Domain Model pattern については以下のサイトを参照
- Exposed Domain Model pattern
http://www.javaworld.com/javaworld/jw-01-2006/jw-0130-pojo-p3.html
◎ Seam と Railsの大きな違い
個人的な感想としてはSeamはステートフルなRailsな感じ。
特にSeamは案外アンチパターンであるStatefulSessionBeanを結構活用しようとしている印象を持った。
Railsの場合はどちらかというとステートレスな方向性だと思うのだが、Seamは逆方向な感じ。
この点について皆本さんは、Seam制作のリーダーであるGavinが
Hibernate（JPA）のLazy LoadingとView層（JSF）との連携をStatefulSessionBeanを使って回避しようという意識が働いているからだという意見を述べていた。
なるほどなぁという感じです。
ただし、この点については、パフォーマンス面、コーディング時の難易度があがるなどの懸念の声があがり、
負荷テストデータは必要だろうなという意見も出る*5。
・・・・書いていたら非常に疲れてしまいましたので気が向いたらこれらについて少々論考を加えたい。
これから、ちょいとはてな上では技術ネタも書いていく予定。
個人的情報発信は最近結構重要だと思っている。
*1:拒否していたのではないな。ひとまず土曜日は大体バタン・キューでさんかする気力がないというところか。
*2:案外リダイレクトを多用するRailsではRequestスコープで消えてしまうものをflashオブジェクトに入れておくということをする。
*3:僕の狭い知識ではJavaでフルスタックのフレームワークはOracleのADF＋BC4Jくらいしか思いつかない。
*4:一般的な SIer の僕の観点からすると大量に人員を投入する関係上、DTOモデルの方が危険が少ないと思っています。
*5:たしか本日のJavaEE勉強会はProEJB3読書会となっており、おそらく、StatefulSessionBeanを利用したLazyLoadingの不具合回避策について議論が行われたはずです。非常に面白い偶然だと思います。ただ、現在の状況からするともしかしたら必然かもしれません
