[東京発] Naoki Ishihara's Blog : Crying over spilt java milk (chats)
Weblog
Profile

石原直樹
日本の Sun Microsystems で Java Technology Evangelist を名乗る。Evangelist としての Java 布教活動(?)の傍ら、JavaOne Japan/Tokyo, Java Technology Conference, Java Computing のような日本での Java イベントのコーディネートも手がける。現在の所属は、Sun Developer Connection. 前職は、Sun 社内の Java Lincensee Engineering チーム所属。その際に培った旧javasoft内での人脈は今でも財産。Sun 入社前は某電話系会社の研究開発部門に所属。
大学での専門は、貨幣論、ロシア経済、哲学など(のはず)。その他の興味は言語/言語学、文化人類学、現代思想など。基本的にエスニック文化に強い関心。趣味はスキューバダイビング(のはず)。


Avator

3D Duke Avator is provided by EitaroSoft
This Duke above is just animation gif but you can see the real 3D Duke in java applet in java.com
アーカイブ
« 12月 2009
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
  
       
今日
XML
Search

リンク
+ top
リファラ

Today's Page Hits: 186

All | General | Java | Java Computing 2005 Spring | JavaOne Tokyo 2005 | Music | OpenSolaris
« NetBeans | メイン | JC2005 Spring »
20050310 2005年 3月 10日 木曜日
EJB and DI
日経 BP の星さんが Blog をはじめた。早速 Linda DeMichiel とのインタビュー記事についての Entry があったが、実りがあったようでなによりだ。今回、Linda には取材の依頼が多く来ている。やはり Press の人たちは敏感だ。旬な話題と、誰がキーパーソンかよくわかっている。
ところで、最近、星さんをはじめ多くの方が DI について Entyr をされているので、私も一言。
DI のようにコンポーネント間の依存を減らし、Runtime まで変数を留保できる考えは、リーズナブルだし、開発者にとってもありがたい。ただ、その DI があたかも既存の EJB と相反するかのような文脈で語られると違和感を感じる。 そもそも、EJB の大きな特徴は、エンタープライズの世界に本格的なコンテナ/コンポーネントモデルを導入したことである。ビジネスロジックをコンポーネント単位にまとめ、エンタープライズシステム特有の処理は極力コンテナに任せてしまおうというものだ。 この時点で、コンポーネント間の依存関係は好ましくなく、あの Home インターフェースや、Remote インターフェースはまさに、そのコンポーネントの独立性、非依存性を確保するために導入された。今日的に言われている DI は、そのコンポーネント志向の延長上にある。EJB2 でいまだに残っていたコンポーネント間の依存関係をさらに減らすのが、DI の要点だと考えることもできる。
EJB に反する考えのように語られることの多い DI だが、それよりは、コンポーネント志向の途上であった EJB の考えをさらに純粋に突き詰めるアイデアと考えるほうが自然に思える。そして、そう考えれば、なぜ EJB3 で、いともあっさりと DI 的要素が取り込まれたか理解できる。
この考え方が私のオリジナルならばかっこいいのだが、残念ながらほとんど丸山先生の解釈をそのまま借用している。こういった逆転の発想的な見方をあっさりできるあたりはやはり先生の慧眼なのだろう。

3月 10日 2005年, 04:16:49 午前 JST Permalink 投稿されたコメント [3]

Trackback URL: http://blogs.sun.com/chats/entry/ejb_and_di
投稿されたコメント:

arclamp.jpのyusukeと申します。 言われることは正しいとは思います。しかし、依存性をなくすべき標準仕様が、その重さ(価格も実装も)のために普及を防げ、開発者にEJB以外の永続化ツールを選択させることで、結果として多くの依存が生まれたのが現実です。それに、EJB3はDIの要素を取り入れますが、ランタイムで重いコンテナに頼るという状況が解決されるわけではありません。 コミュニティが言うDIの目的は軽量化です。そういう意味では、相反すると考えるべきです。 EJB3で技術的にDIを取り入れたとは思いますが、コミュニティの期待には答えられていないと思います(EoDには効果ありますね)。

Posted by yusuke on 3月月 10日, 2005年 at 07:47 午後 JST #

yusuke-san, まさか yusuke-san からコメントいただけるとは。光栄です。さすが、ポイントを簡潔にまとめられていますね。そうなんです、アンチ EJB 的コミュニティが言うところの DI は、ライトウェイトコンテナと不可分になっているのです。しかし、DI的な要素は、コンテナが重量級だろうが軽量だろうと適用できるはずです。そこが分かっていない人だと混乱してしまいますね。
軽量コンテナを志向する動きのあることはむしろ好ましいことだと思っています。多くの選択肢があって悪いわけがない。むしろマーケットの需要を正確に測る上では選択肢が多いことは重要です。そして今、軽量コンテナへの志向が強いということはマーケットの需要が強いということです。EJB3 も、軽量コンテナを意識していると思える部分があります。
今後、EJBが軽量への傾倒をさらに強めるとすれば、それはまさしくyusukeさんの言われるコミュニティの成果だと捉えてよいかと思います。
つまり、EJB は、DI のみならず、軽量化についても別に矛盾しないのではないでしょうか。EJB および J2EE にとってのゴールは、高価格でも重量コンテナでもなく、エンタープライズ分野における最適な Java プラットフォームですので、軽量コンテナが better なのであれば、その方向に進化するでしょう。価格も、コンテナの重さもすでにその方向に進みつつあるように思えます。
コメントもらったのがうれしくて、大した意見ではないのについ長々と書いてしまいました。

Posted by chats on 3月月 11日, 2005年 at 12:53 午前 JST #

arclamp.jpのyusukeです。 そう、前向きにはEJBが軽量化することを評価すべきですよね。あとは、EJB3が、どこまで軽量化し、どういう永続化モデルを示せるかが見ものです。chatsさんのコメントで、あらためて、いろいろ感じることがありました。まとめて、エントリしてみます。 (今見たら、自分のコメントが高飛車な物言いですみません、仕事の合間に書いたということで、お許しくださいませ)

Posted by yusuke on 3月月 11日, 2005年 at 10:14 午前 JST #

コメント

名前
メール
URL

投稿されたコメント

HTML文法 不許可