スタラジ補足 EJB

スタラジで意外なくらいにEJBが話題になってびっくり．Spring + Hibernateになるとかいう噂のEJB3.0が相当期待されているようです．
でもですね，そのSpring + Hibernateなものって本当にEJBなんですかね？全然別物じゃん！？って思っちゃいます．そもそものEJBとあまりにかけ離れているように感じるからです．
それは，EJBというものがどんなものかという認識に違いがあるからかもしれません．ということで私がEJBというものをどう認識しているかを書いてみるテスト．これはあくまでも個人的な思いこみなのでそこんとこよろしくです．
EJBを使っている人によると，EJBを使うメリットは宣言的トランザクションが使えることらしいです．確かにそれは魅力的．なんですが，それはEJBにとっておまけみたいなものに過ぎないと思います．EJBの本質は，
分散オブジェクトの コンポーネント
だと「私は」思っています．
EJBの壮大な野望は，「ビジネスコンポーネント」をかつてのVBX/OCXのように流通させることにあったのではないでしょうか．ここでいう「ビジネスコンポーネント」は，かなり粒度の大きなコンポーネントで，もしかしたらERPの○○モジュールみたいな感じでしょうか？というのも，EJBの策定にも大きく関わったであろうCORBAな人達がそのような考えを示していたからで，それは例えば「ビジネスコンポーネントファクトリ (isbn:4798100935)」で窺い知ることが出来ます．個人的には，この頃に「ビジネスコンポーネント」として話題になっていたアイディアには共感できませんでした．まったく現実的ではないと思えたからです．
このテーマの多くはCORBAの人達から出てきていたのですが，実はCORBAの使い方にもいろいろあります．書籍などのサンプルでよく出てくるのは，ドメインモデルのオブジェクトをそのまま分散オブジェクトとして実装するような方法で，特に銀行(Bank)と口座(Account)の例を見かけることが多いですね．その場合，口座の数だけ分散オブジェクトと作ることになるわけで，CORBA~~2.3(だったかな？)~~2.2(だったらしい，id:shot6さん，どうもです)で導入されたPOA(Portable Object Adapter)はそのような実装を効率的に行うためのものだったりします．
しかしですね，CORBAでそのような実装をした場合，かなりの確率でパフォーマンスの問題にぶち当たったはず．いくら昔と比べてネットワークが速くなったとはいえ，それでも遅いことに変わりはないのです．結局の所，分散というかリモートなオブジェクトというのは，粒度を大きくしてインスタンスとインタフェースの数を減らさないと実用にはならないと思うのです．今では，それはセッションファサードとしてよく知られているわけですが．
話を「ビジネスコンポーネント」に戻すと，これは「細粒度の分散オブジェクト」を「大粒度のコンポーネント」にパッケージングするという，なんとも非現実的な代物という風に私の目には映りました．
EJBは，この「ビジネスコンポーネント」を目指して考案された仕様であるように思います．エンティティビーンなどという分散かつ永続的なオブジェクトの存在がその根拠．最初から使い物になるわけがないのです．
それでもEJBは注目と期待を集め続けてきたようですが，多くの人が必要としたのは「ビジネスコンポーネント」を実現する技術としてのEJBではなく，単に宣言的トランザクションやO/Rマッピングを使いたかっただけというのが現実のようです．不幸にも，それらを実現する最も身近な存在がたまたまEJBだった，というだけのこと．EJBもそれに応えるためにLocalインタフェースを導入したりしていますが．．．生まれの悪さ(複雑！面倒！)はどうしようもありません．
しかし，もはやEJBを使わなくてもDIConとHibernateなどを組み合わせれば，宣言的なトランザクションやO/Rマッピングを手にすることが出来るのです．素晴らしい．
それではEJBに残されているのは何か？「分散」と言うことなんですが，前述のようにこれの現実的な使い方はファサードとしての使い方です．このファサードを突き詰めていくと，きわめて汎化されたエントリポイントに成り下がっていきます．そのようなファサードは，改めてEJBとして実装しなくても，もっと手軽に利用することが出来ます．それはServletです．
かつてCORBAなどの分散オブジェクトが期待されていた頃は，まだHTTPを用いたWEBベースの技術がここまで普及(進歩)するとは考えられませんでした．「分散」オブジェクトを使うシチュエーションというのは，ちょっと前によく耳にした3層C/Sのような世界だったのです．
しかし，時代はすっかり変わってしまいました．現在では企業内のシステムでもWEBベースの技術で構築することが一般的だと思います．HTTPを使ってサーバ側と連携するRIAもいろいろな選択肢がありますし，SOAPもあったりします．
ということで，Servlet + DICon + Hibernate でEJBは不要，EJBはすでに死んでいる！というのが私の結論です．これ，本音としては自分でもちょっと短絡的かなと思っていたりするのですが，たいていの場合EJBを使わなければならない理由はもはやないと思います．
そんなわけで，正直EJB3.0もどうでもいいです．DIConはもはや必須だし，HibernateのようなO/Rマッピングツールもいいでしょう．でも，それがEJBとして仕様化される必要はないはず．ましてやDIConを標準化するのなら，それはJ2EEじゃなくてJ2SEにあってもいいと思うのです．

ところで，この日記ではSpring FrameworkやHibernateの入門記をやっているわけですが，その原点が実はEJBだったりします．かつてNIFTYのFRPOGPRO OO会議室で，仕様書を読みながらEJB入門記を書いたことがあるのです(サンプルはもちろんカウンタ)．EJB1.0がリリースされた年，Java2(JDK1.2)がリリースされた頃だったので，1998年の終わり頃でしょうか．BEAに買収された直後のWebLogicのバージョンは3.xだったかな．NIFTYとはいえ，それなりに公開された場所にEJBのことをまとめて書いたのは日本ではかなり早かったと思っています(JavaWorldにEJB特集が出たのは翌年の春でした)．
その時入門記に書いたのはSessionBeanまでで，そのあとEntityBeanについて書くつもりだったのですが，仕様書を読んでいるうちに興味をなくしたことを覚えています．(^^;
そうなんです，私にとってEJBは，98年にはもう死んだのです．合掌．