koichikさんのEJBについて

これは納得というか、なるほど!!!って感じです。
僕個人は分散プログラミングでCORBAを少しかじったことがあるので
その辺りの部分も共感できることが多いです。ちなみにPOAはCORBA2.2から加わったもので、
僕はCORBA2.1準拠のORBしか触ったことがないので、POAの実装は良く知りませんが、
BOAの曖昧さを殺ぎ落とした部分については評価できると思ってます。ただ性能は期待できないなあというのはCORBA準拠のもの全てに感じています。

たしかにEJBの理想である「分散コンポーネント」としての仕様という壮大な夢は
HTTPベースのWeb環境の普及により、からまわりしているのかもしれません。
(このあたりの空しさ感はCORBAのときとちょっと似ています。最近少しCORBAが復活の兆しが見られるようですが。。。)
それより現場の人々に求められているのは、koichikさんも仰っているように宣言的トランザクション
O/Rマッピングなどをもっと手軽に使えるようにしてほしいのです。

そして、以下の部分。これはかなりおお!という感じです。

それではEJBに残されているのは何か?
「分散」と言うことなんですが,前述のようにこれの現実的な使い方はファサードとしての使い方です.
このファサードを突き詰めていくと,きわめて汎化されたエントリポイントに成り下がっていきます.
そのようなファサードは,改めてEJBとして実装しなくても,もっと手軽に利用することが出来ます.それはServletです.

かつてCORBAなどの分散オブジェクトが期待されていた頃は,まだHTTPを用いたWEBベースの技術がここまで普及(進歩)するとは考えられませんでした.
「分散」オブジェクトを使うシチュエーションというのは,ちょっと前によく耳にした3層C/Sのような世界だったのです.

しかし,時代はすっかり変わってしまいました.現在では企業内のシステムでもWEBベースの技術で構築することが一般的だと思います.HTTPを使ってサーバ側と連携するRIAもいろいろな選択肢がありますし,SOAPもあったりします.

ということで,Servlet + DICon + HibernateEJBは不要,EJBはすでに死んでいる! というのが私の結論です.
これ,本音としては自分でもちょっと短絡的かなと思っていたりするのですが,
たいていの場合EJBを使わなければならない理由はもはやないと思います.
そんなわけで,正直EJB3.0もどうでもいいです.DIConはもはや必須だし,HibernateのようなO/Rマッピングツールもいいでしょう.
でも,それがEJBとして仕様化される必要はないはず.ましてやDIConを標準化するのなら,それはJ2EEじゃなくてJ2SEにあってもいいと思うのです.

エントリポイントとしてServletを使うか・・・いや考えたこともなかったです。
なんか妙に納得してしまいました。。。。

たしかに何の制約もなければServlet+DICon+Hibernateという選択肢はかなり魅力的です。
つか現時点でのベストな選択肢であるかもしれません。
レイヤをきちんと分割し、かつpersistenceレイヤでは、O/Rマッピングにより、
より実装者の負担は減ります。うーむ、凄い。
(スタラジのときに高井さんが仰ってましたが、実はこうするとトリッキーな事はかなり実現しづらくなります。
なので実装するとつまらない・・・のかもしれません。ただし品質は高水準で保たれるのは明白でしょう)

ちょこっとだけ気になる点としては、
・現時点ではDIの仕様がない。(koichikさんも仰っているようにJ2SEもしくはJ2EEの仕様として組み込まれてない)
そうなると現場への適用はソフトウェア単位になるのでそのツールのつくりに依存してしまう。
・お偉い方は仕様に弱い(--;)
O/Rマッピングの仕様ってあったっけ?

そんなもんでしょうか。素人考えですが・・・

参考文献はkoichikさんの以下の日記です。

●koichikさんからのすばやいレス。恐縮です(^_^)

追記。ServletJAX-RPC経由でWebサービスエントリポイントもてるのですね。
知らんかった〜。つーか知らないことだらけじゃ〜〜〜
えー、世間に生き恥をさらしつつ生きております。ま、こんな奴なんで。