JSUG勉強会Vol.4に参加してきました

Japan SpringFramework User Groupの 第4回勉強会に参加してきた。ミニレポートをエントリしてみたいと思う。 [JavaOne2007報告] 日立の河村さんのプレゼン。これは5月30日に行われたJavaOne2007報告会で行われたプレゼンとほぼそのままだったので,聞くのは僕個人的には2回目。 前にエントリした通りの内容なので,そちらを参照のこと。 2回目を聞いた感想としては,やはりglassfish v3はやっとかないとあかんな,と。あとJavaOne報告会でなかったこととして,Sunが参加者に向けて示したスライドの「ありがとう」を伝える各国の言葉について, 「Thank you」 「Gracius」 「Merci」 「謝謝」 「元気です」 「なんで?」という日本人限定のネタがあったらしい。うーん,日本Sunの誰かが仕込んだとしか思えない。 [ライトニングトーク] CTCの梯さんによる,Springを活用した社内フレームワークの紹介。5年前に作ったフレームワークにSpringFrameworkを取り入れた際の話だった。社内フレームワークは,Strutsベース,独自のO/Rマッピングツール,各種ライブラリ(メール送信などcommons系に似たライブラリ),ドキュメントがセット。ある程度目的は達成されたが,今風の問題点(特定OSSへの依存やTxまわり,アーキテクチャの一貫性,そもそも流行に乗ってない)がでたらしく,Springを導入。その結果,問題点が解決したらしい。高機能なAPIというよりは,一貫したルールを開発者に言えるようになった点が強調されていた。 CTC内部で月に2,3回研修会をやっているようで,普及活動が進んでいると。.netをクライアントに,そしてサーバをJavaで,という形態を模索しているっぽく,確かに何かあると嬉しいかも。glassfish v3でその辺の対応がされるらしいので,試してみるのも面白いかもと思った。 SpringFrameworkを組み込んで逆に発生した問題点として,導入前までの教育コストをまた費やさなければならなくなってしまった(逆にコスト増)らしい。うーん。 [Spring MVC & Web Flow] ATLの方々によるSpring MVCとSpring Web Flowの話。内容としては,Spring MVCが開発された背景,既存のフレームワークとの比較,適用した場合の効果など。 Spring MVCの開発背景ということでアジェンダが語られていたが,Strutsと他のOSSとの組み合わせでアーキテクチャを考えた場合に依存性からくる統合のコスト(テストしにくい)がかかるというDIパターンの話があげられていた。これは,Spring MVCの背景というよりSpringFrameworkの背景が説明されている点がちょっと残念。と思ったが,フレームワークの進化という説明でPage Controller→Front Controller(Struts MVC)→Spring MVCの比較スライドがあった。StrutsとSpring MVCは「基本的に同じ」なのだが,Spring MVCのProcessing Pipelineに様々な機能がStrategyパターンで拡張可能な点が相違点だということだった。DispatcherServlet#doDispatch()から,各Strategyをルックアップ(=getBean())しているコードが紹介された。なるほど,と。getBean()できなかった場合はデフォルトのStrategyを適用する,というコーディングは最近の流行「Convention over Configuration」が反映されているように見えて,ちょっとキュンとなった。 次の問題提起として,ControllerやViewなどが独立された結果,アプリケーションの状態管理どーすんの,という話が登場。結局アプリケーションは会話的やり取りが必要であり,状態というものを管理しなくちゃいけないよね,と。多くのユースケースはServlet仕様をベースにしたモデリングでは自然ではなく,例えばセッションの情報は,状態に応じて削除したりしないといけないよね,と。昨年僕が担当したシステムでは,状態をファンクションという単位で管理し,その中でセッションを掃除したりする機構を作ったが,間違いではなかったなと自画自賛。Finite State Machine(FSM)という言葉は初めて聞いた言葉であるが,昔から確立されているものらしい。 Conversational Scopeの例として設定ファイルのXMLが紹介されたが,view-state要素やsubflow-state要素など,ShaleのDialogの定義内容とほぼ一緒だな,という印象を受けた。シーケンス図などで内部の処理が紹介されていたのだが,Web Flowの基本概念を知らない人にとっては,ちょっと難しい内容だったかも。Spring Web Flowを使うときに開発者が書かなければいけないコードの紹介がなかったため,「状態遷移ってすっげー複雑!」という印象のみが強く残ってしまった。 1人のクライアントが複数の別のステートを共有できるかどか,という質問について,Sub Flowという形で持つことになるとの回答。ShaleでいうSub Dialogのことだろう。Conversationの管理については,HttpSessionとの割り当てで管理されるのがデフォルトだが,そこを切り替えることは可能。つまり,デフォルトだと,ConversationはHttpSessionのタイムアウトによって終了したりすると。ブラウザの戻るボタンが押されたときはどうなるか,という質問は,基本的にフォローできるように作られているが,細かな問題がでることはでるので,実装ルールを作って対応することになると。 Spring Web Flowについて,少なくとも数十万ステップではATL内では適用しているが,日本国内の事情は不明。 JSFとの統合が進んだことは河村さんのプレゼンでもあった通り。 [その他] そう言えば,初回の勉強会(java-ja第1回と重なった時)は,飲みにきてた人の人数から想像して,かなりの人数が参加していたはずなのだが,今回の勉強会の参加者はさほど多くなかったというのが印象に残った。ま,とはいえ,豆蔵のトレーニングセンターで席がいっぱいになるくらいにはなっているので,勉強会としては多い方かもしれない。 [勉強会メイン(≒飲み)] 田舎に住んでいる僕は,今回の勉強会も正味30分で帰宅の途についてしまった。しかし,「 twitter4j作者の山本さん」「 WINGSプロジェクトの佐藤匡剛さん」と同席させていただくことができた。twitterclipse作者としては,山本さんと何かコラボできたらいいな,と。そして佐藤さんとは,何か共通のテーマを見つけて共著できたらいいな,と。そんな会話が実現できるのも,勉強会の醍醐味である。 S2Wicketをやってる都合上,どうしても「seasarな人」っていう印象が僕に対してあるっぽい。SpringFrameworkな何かを早急に模索せねば,と固く心に誓ったJSUGの夜だった。

このエントリーをはてなブックマークに追加

関連記事

2023年のRemap

Remapにファームウェアビルド機能を追加しました

Google I/O 2023でのウェブ関連のトピック

2022年を振り返って

現在のRemapと今後のRemapについて