SeamとWebアプリケーションのアーキテクチャについて

Teeda JavaEE


InfoQでFloydがGavin Kingにインタビューしてます。
これは色々と学ぶべき点・これはちょっとどうかなと思う部分あるので
以下を超訳でまとめてみました。間違いあれば突っ込みくださいｍ（＿　＿）ｍ


http://www.infoq.com/news/JBoss-SEAM-1.0-Gavin-interview


■Seamの利点
1.A Unified component model centered around EJB


今までだと新技術が登場するたびに新しいコンポーネントモデルが
必要だったけど、Seamを使うとJSF/EJB/Ajax/jBPMを基本に
共通のコンポーネントモデルを使うことができる。
SessionBeanはJSFのActionListener/managedbeanになる。
EntityBeanは直接Formから呼び出される？



（shotの意見）
最後の一文が引っかかります。
EntityBeanは直接Formから呼び出されるってことは
Presentation層からDomainModelを直接呼び出すの？
それって今までの良くない点とあまり変わらない気が・・・・

アーキテクチャな話は、ひがさんの日記参照。

２．Raises semantic level of development（抽象度の高い開発？）

フレームワークのコードを呼び出すなんて、いまどきありえなくて
Aspectがあって、jBPMのようなDSL的なものもあるから
より抽象度の高い開発が可能。



（shotの意見）
ここは基本的にagreeです。jBPMは余計ですけど。
DI/AOPをベースにすると、開発自体はフレームワーク依存のコードが
減って、抽象度があがるというか使いやすいModelがPOJOとして
残るとは思います。かくたにさんや和田さんが言っている
「POJOとそのテストコードが最大の資産である」という考えは
言い方を変えれば最後まで残るのはモデル（POJO）であって、
それこそが非常に重要だと感じています。


Seasarファウンデーションで考えると、BuriがjBPMの位置に
くるんでしょうね。


３．Contextual Model higher level of state management over HTTPSession
（より高度な状態管理）


SeamではConversationとProcessという状態管理Modelがあるので
単なるHttpSession依存の状態管理方法より、抽象度が高く意味のある
単位で状態管理が出来る。この状態管理Modelを持ち込むことで、
戻るボタン対策, リフレッシュボタン対策, ダブルサブミット,
複数Window対策、post then redirectsにも対応できる。
ConversationはConversationIDなるものを持っていて、HttpSessionから
状態を取ってこれる。SeamはJSFをベースにConversationIDを
実装しているので、ユーザーからは透明（らしい）
SFSBも透明・・・らしい



（shotの意見）
Conversationで、戻るボタン対策, リフレッシュボタン対策, ダブルサブミット,
複数Window対策、post then redirectsに対応できるのかちょっとわからない。
特に複数Window対策はIEでは厳しいような。。。。（Session同じだし。FireFoxならいいけど。）


（追記）
戻るボタン対策, リフレッシュボタン対策, ダブルサブミットとかはわかったけど、
複数Window対策かなあ。でも基本的にConversationの考え方で
状態のライフサイクルにバリエーションがあるのは素敵だと思います。
アノテーションが多すぎるのは考え物だけど。


４．DRW-style AJAX EJB invocation and the ability to recieve JMS
messages in the browser


EJB3のSession beanがJavaScriptとして実現される。
JMSでもブラウザからダイレクトにメッセージ投げれるみたい・・・・
DWRから、アノテーションで実現。



（shotの意見）
ここ違和感があった部分。
これって、DomainModelのContextを完全にプレゼンテーションに持ち込んでいるように
見えるんですけど。いいのかな。おいらはこれはなんだか嫌な感じがします。
EJBがJavaScriptとして見えるなんて怖すぎると思うのは臆病だからでしょうか。
Viewと、Domainを同一に扱う話はこの後にまとめて出てきます。

５〜７

あんま重要そうじゃないので割愛。
テストは簡単に出来るそうですｗ


ここからは五月雨式に文書を超訳。
■Webbeansについて
Gavinこう言ってます。
"It's great to innovate in open source, but there are a great mass of
developers that can't use stuff unless it's blessed by a big company
like Sun and IBM. If we want to solve problems for these people then
it needs to be part of the standards."

こういうのがOSSで出てくるのは凄いけど、ベンダが支援してくれないと
こういうのってみんな使えないよねえ〜。ふむ。


■実行環境について
あとは、Gavinは実行環境については、きちんとしたApplicationServerで
Seamを動かすことをお勧めしてます。なんか、TomcatでもJBoss Micro containerを
使うと動くみたいですけど。GavinはTomcatあんま好きじゃないみたいです、
Deployとか管理の部分で。まあJBoss使ってね、ってことなんでしょうか。
ベンダ的にはそういう意見になるよね。


■レイヤーモデルとSeam


基本的にSeamを使うと、レイヤーモデル間の境界が曖昧になるので
サービスレイヤーはどこに配置すべきか？という質問に対して
Gavin曰く
１．すべてのApplicatioｎがレイヤーモデルが必要なわけじゃない。
簡単なモデルだったら、プレゼンテーション層とパーシステンス層だけでいいんじゃないか？

２．レイヤリングだけが関心の分離をする方法じゃない。もっと良い方法は、
ビジネスロジックをドメインモデルとほかのオブジェクトにリファクタリングする方法だ。
関心を分離するのに、レイヤーモデルを乱用する必要はない。

３．業務フローと業務プロセスは全部jBPMにやらせて、残りの
Javaコードはきれいで抽象度の高いロジックだ。全部とは言わないけど
関心はよく分離できていると思う。



（shotの意見）
うーん、Gavinレイヤーモデルをこうやって捕らえているとは思いませんでした。
特に違和感があったのが１と２です。
将来Applicationの修正・拡張を考えると個人的に１は無いんじゃないかと
思うわけです。
そして、２が正直よくわからない。？？？？って感じです。
おいらの意見は、Seasarの開発で標準的（？）だったThin Domain Modelが
好きで一番しっくりくるというか、無理がないように見えるので
それが良いと思ってます。

なんか一緒くたにするのが苦手なのかも。
SRP(Single Responsibility Principle)をなるべく守りたいのかも。


（追記）
Gavinがレイヤ分割をやめろとは言ってないです。念のため。
フレームワークがレイヤリングを強制するようなのは良くないよとこう言っているようです。（Thx izuさん＾＾）


ちなみにSeasar2では強制されるレイヤリングはありませんよ、念のため＾＾

■その他
ちなみにインタビューしているFloydは、JSFが好きじゃないので
インタビュー中でも食い下がってます。なんでJSFよ？とｗｗｗ
GavinさんはELが好きだそう。ああ、たしかに。

そういやあFloydとRodはJSF嫌いって言ってたな。
Webを難しくしすぎていると。おいらはそうは思わないんだけどなあ〜。
JSFは問題点もありますけど、良いところも結構あると思います＾＾