2004-06-26

06/06に書いた「スタラジ補足 EJB」がなぜかFreeMLのjboss-fan-mlで話題になっていたようです．といいますか，相当反感を買ってしまったようです．うーみゅ．(;_;)
自分の意見をインターネットに公開する以上，同意してもらえなかったり反感を買ったりすることは避けられないとは思っていましたが，さすがにそういう事態を目の当たりにしてドキドキしちゃいました．小心者なんです〜．
その怒りの投稿をした佐藤一憲さんという方ですが，JavaWorldでおなじみの吉川和巳さんと同一人物なのですか？ちょっと不思議な感じですが，吉川さんの記事は大好きなので，直接コメントもらえたら嬉しかったかも．
でも，あの勢いでコメントされたらこちらも戦闘モード突入は必至だったのでこれでよかったかも？ (^^;
ともあれ(笑)，なんの関係もないはずなのに佐藤さんの怒りの矛先を向けられてしまったjboss-fan-ml読者の皆さんや，オーナーのid:mikiさんにはちょっと申し訳ない気分です．あと，フォローに行ってくれたっぽいひがさんにも少々．(^^;
そんなこんなでどうなるのかとドキドキしながらMLを眺めていたのですが，「JBoss入門 (isbn:4774117498)」の著者id:mikiさんと「EJB+J2EE入門 (isbn:4872804996)」の著者(？)佐藤さんという期待の組み合わせの割には，あまり技術論で盛り上がることなく収束してしまったようです．たぶん．もう1週間くらいメールが流れていないようですから収束ですよね？
ということで，火に油を注がないように静観していた私もそろそろ何か書いてみるテスト．

まずは反省から．
ちょっと文章が長かったかなぁ．そして終盤に「EJBは死んでいる」と刺激的な表現を使ってしまったために，始めの方で書いたことは読者の記憶に残っていないのかなって思いました．

出だしのところで私は次のように書きました．

スタラジで意外なくらいにEJBが話題になってびっくり．

つまりですね，世間的にはEJBは死んでいないのです(スタラジ参加者がはたして世間一般かという疑問はとりあえず封印しましょう)．それが現実です．私があのような日記を書いたきっかけは，私にとっては過去のものになっていたEJBが現在もしっかりと使われていて，将来に期待もされているということに驚いたからなのです．
ですから，「EJBは死んでいる」のが一般的な認識であるとか，普遍的な真理であるとか考えていたわけではありません．ましてや，私は次のように前置きしています．

ということで私がEJBというものをどう認識しているかを書いてみるテスト．これはあくまでも個人的な思いこみなのでそこんとこよろしくです．

ね？結構予防線を張っているでしょう？(^^; 自分の意見は間違っているかもしれない，間違っていないにしても少数派だろうという自覚はあったし，そこに注意して欲しいということを表明したつもりでもあったのです．
ま，いかに予防線を張ろうとも，私が「個人的な思い」を表明する自由があるのと同様，それを読んだ人が怒りや反発を表明する自由があるわけで，どうしようもないかな，と思ったりもしますが．

さて，前の日記で私はEJBに対する自分の考えを次の構成で書きました．

前提: EJBは分散オブジェクトのコンポーネントである．
現状: 分散オブジェクトが必要とされていた時代は終わった．
結論: EJBは死んでいる．

佐藤さんには結論の部分で反発されてしまったのですが，結論は必然的に導き出されたものであり，問題は前提か現状のどちらかにあるはずです．MLへの投稿を見ている限り，現状の認識では差異はあまりない(分散オブジェクトは必要ない)ものと思われますから，前提の部分に大きな認識の違いがあるのではないでしょうか？
それは予想していたことでもあります．ですから前の日記では，

Spring + Hibernateになるとかいう噂のEJB3.0が相当期待されているようです．
でもですね，そのSpring + Hibernateなものって本当にEJBなんですかね？全然別物じゃん！？って思っちゃいます．そもそものEJBとあまりにかけ離れているように感じるからです．
それは，EJBというものがどんなものかという認識に違いがあるからかもしれません．

と書いています．つまり，多くの人が認識しているEJBと，私が認識しているEJBは，もしかしたら違うのかもしれない，ということなのです．ここ重要です．
それで，私が認識しているEJBというものの説明をその後に書いています．それが流通可能な「分散オブジェクトのコンポーネント」であり，「ビジネスコンポーネント」であるわけです．繰り返しますが，ここ重要です．
なぜ重要かというと，それがEJBが目指したもの，目標，夢，理念，ミッションであったと思うからです．これは，今現在でも有効です．というのも，現時点で最新であるEJB2.1の仕様書においても，「2.1 Overall Goals」の筆頭項目として次のように書かれているからです．

The Enterprise JavaBeans architecture will be the standard component architecture for building distributed object-oriented business applications in the Java programming language.

ね？これがEJBのゴール，目指しているものです．もう一度書きますが，ここ重要です．
EJBが備えるコンテナ管理のトランザクションや永続性やセキュリティやキャッシングやプーリングその他諸々は，この目標を達成するために(たまたま)必要となっただけであり，本質ではないと思うのです．ですから，トランザクションや永続性を始めとする様々なサービスを理由にEJBを使おうと考えるのは，目的と手段を間違えているような印象を受けます．手段を目的にしてしまっているような感じということです．
EJBを特徴づける要素の一つがデプロイメントです．EJBを支持する佐藤さんも，これはお気に召さないように窺えます．しかし，デベロップメントとデプロイメントの分離は，EJBの理念の上では重要です．なぜならEJBでは，コンポーネントをどこかから調達してきてデプロイして使う，という世界を目指していたはずだからです．デプロイという面倒な作業は，コンポーネントを調達してきてブラックボックスのまま使う人のための工程なのです．最初から開発者のためのものではありません．
しかし，現在EJBを利用している人というのは，コンポーネントを調達してきて使っているのでしょうか？あるいはEJB コンポーネントを作っている人というのは，コンポーネントを流通させるために作っているのでしょうか？おそらく違いますね．大多数の人は，これから運用するシステムのみのために，カスタムなEJBを作っているのではないでしょうか？それは，EJBが目指した世界とは違っているように思います．
ということで，前回書いた結論を補足すると，「EJB(が掲げている理念)は死んでいる」ということになります．これはあくまでも個人的な思いこみなのでそこんとこよろしくです．(こぴぺ)

と，ここまで書いてきて思うのですが，佐藤さんとは議論がかみ合わないかもしれませんね．佐藤さんはEJBの目標や理念なんて，全く話題にしておられませんから．ひたすら「アプリケーションサーバが提供する多種多様な能力」こそがEJBを使う理由なのだ，と主張されている様子．
でもですね，それって会社の理念とは相容れないけど給料が高いから就職するっていうのと似ていて，とても幸せになれそうな気がしないのですけど．(^^; ま，何が幸せかは人それぞれですけどね♪

さて，これが私のEJBに対する考え方なのですが，ご理解頂けたでしょうか？えぇ，もちろん同意して頂く必要も納得して頂く必要もありません．単に，「そういう考えもある」ということをご理解頂ければ十分という感じです．それさえも must でないことは言うまでもありませんが．

そうはいっても，現実にEJBが便利なものであれば，理念がどうとか理屈をこねてないで使おうよっていうことになりますよね．これまで分散オブジェクトのコンポーネントを作りたいわけでもないのになぜかEJBを使ってしまった人たちは，EJBの実利を評価して採用してきたのでしょう．そんな実利の代表が宣言的トランザクションとO/Rマッピングであったというのは，この前のスタラジでも，それ以外のところでも，だいたい一致しているようです．
しかしながら，もはや宣言的なトランザクションやO/Rマッピングだけが理由でEJBを使う必要はありません．そんな皆様のために，DIConがあるのです．
誤解しないで頂きたいのですが，EJBを使う理由が宣言的なトランザクションやO/Rマッピングだけだといっているのではありません．宣言的なトランザクションやO/Rマッピングだけを理由にEJBを使うことはない，といっているのです．論理的に考えればお分かり頂けると思いますが，全然違う話なのでご注意願います．
つまりですね，実際にEJBを使っている人たちでも，多くの場合EJBからはその程度のメリットしか引き出していない(必要としてない)のが現実ではないか，ということです．それでもいいじゃないですか．別にEJBを使い切ることが目的じゃないのですから．
そういう，これまで普通に(っていうのも変ですが)EJBを使ってきた人の大多数は，もはやEJBを使う必要はないでしょうってことです．もっと手軽で簡単で優しくて易しいDIConがあるのですから．おっと，優しくて易しいはS2にのみ適用ということでよろしくです．

それから，Srping + Hibernate みたいになるという噂のEJB3.0について．
EJB3.0に導入されるという個々の技術はきっと悪くないのだろうと，私も思うのです．しかし，それをどうしてEJBという仕様の中でやらなくてはならないのかが分からないのです．
Dependency Injectionは，EJBに限って必要なものでしょうか？違うと思います．O/Rマッピングもそうです．これらは，EJBとは独立した仕様の方がいいと思うのです．特にDIは，例えばSwingを使ったクライアントアプリケーションでも効果的でしょう(SeasarProjectの「sami100のSwingin' Seasar日記」を参照願います)．ですから，EJBどころかJ2EEで仕様化することさえ疑問に思います．前の日記でも書いたように，J2SEの一部にして欲しいのです．
標準は重要です．DIConにおいても，標準となる仕様が望まれます．しかし，それがEJBに含まれることには反対というのが「私の」意見です．

さて，今度は佐藤さんのご指摘について書いてみたいと思います．
MLでの指摘に日記で答えるってどうよ？っていう気もするわけですが，元々この日記から始まった話題だし，このテーマがMLの方で歓迎されている様子でもない(JBossの話題じゃありませんからねぇ)ことから，一応ここに書いてみます．
その上でですね，もし佐藤さんがこれをお読みになって，こんな私と議論を続けていくことを望まれるのであれば，WikiかMLかに移りたいと思っています．その場合は新しい場を用意するつもり．あるいは(むしろ？)宴会がてらの議論も大歓迎♪
ともあれ，佐藤さんが今でもこの日記を読んでくださっているのかさえ定かではありませんが，MLから引用しながら異論・反論・オブジェクション！してみたいと思います．

EJB不要論を唱える人は、要するにO/RマッピングとTX管理「だけ」が必要な人であって、アプリケーション・サーバに備わるその他の多種多様な能力（セキュリティ、リソースプーリング、トランザクショナル・コンポーネント、分散キャッシュ、クラスタリング、分散TX、ORB、MQ、ディレクトリサービス、運用管理ツールetc）は必要のない人（または知らないので使おうと思わない人）だと思うのです。

もうひとつ．

話を戻しますと、「EJBは死んでいる」という主張は、「EJBのような豊富なJ2EE機能は不要」と私には聞こえてしまいます。「デザインパターンがなくてもコードは書ける」という主張に似ていると思うのです。

ふむ．ちょっと異議ありです．おっと，異議があるのは「知らないので使おうとしない」の部分ではないです．知らないものは使えないってのは間違いありませんから．
ここで佐藤さんが示された，アプリケーションサーバの「多種多様な能力」ですが，果たしてそれはEJBでのみ利用できるものなのでしょうか？違うと思うのですよね．
佐藤さんが示された「多種多様な能力」の多くは，EJBという仕様の外側で規定されています(全てではありませんが)．セキュリティ(JAAS,JCE,JSSE)，トランザクション(JTA,JTS)，ORB(RMI,JavaIDL)，MOM(JMS)，ディレクトリサービス(JNDI)，ツールではありませんが運用管理(JMX)などなど．
私には，佐藤さんのご指摘はEJBとアプリケーションサーバを混同しているように思えます．アプリケーションサーバの能力を使うには，EJBを使うしかない，という論調に見えるのです．あるいは，EJBを使わないということは，アプリケーションサーバの能力を使わないということだ，という論調に見えるのです．それはどちらも間違っていると「私は」思います．
EJBというのは，アプリケーションサーバが提供する多種多様な能力を，よりソフィスティケートされた形でアプリケーションから利用できるようにしてくれる仕様ではないでしょうか？
そこで問題になるのは，アプリケーションサーバの多種多様な能力を使うベストな方法は？ということです．これまではEJBだったのかもしれません．しかし今でもそうなのか？これからもそうなのか？ということです．
DIConが使える今，私はNoだと思っているのですが，これからもEJBに期待している人の答えはきっとYesなのでしょうね．その理由が私には見えないのですが．

今後、SpringやSeasarがORMとTX管理以外のJ2EE機能を実装していけば、POJOベースであるということ以外に、現在のJBossと何ら変わりのない様態となるだろうと思います。

それからもうひとつ．

ですから、今後、

・ORM用DIコンテナ
・TX管理用DIコンテナ
・セキュリティ管理用DIコンテナ
・運用管理用DIコンテナ
・オブジェクトプーリング用DIコンテナ
etc etc

とどんどん増えていけば、それはすでに「サーバ」ではないでしょうか。

佐藤さんはDIConについて誤解をされているように思います．
DIConは，どこまでいっても「サーバ」にはなり得ません．というのも，実行スレッドを提供しないからです．
DIConは，(必要なら)アプリケーションサーバが提供するスレッド上で動作します．
それから，トランザクション管理やセキュリティ管理といった機能は，コンテナ自体がサポートするとは限りません．例えばSpringもS2も宣言的なトランザクションをサポートしますが，これはコンテナによって提供されているとはいえません．S2については，トランザクション属性の設定についてコンテナが直接サポートしていますが，トランザクション管理自体はコンテナの外部で行われています．その一つがS2Txとして提供されるJTAの実装ですが，それ以外にWebSphereやWebLogic，それにJBoss等のJTA実装を利用することもできます(その設定例がこちら)．
DIConは，アプリケーションサーバが提供する豊富な機能をソフィスティケートされた形で利用できるように，基本的なメカニズムを提供してくれるだけです．付加的な機能の多くは，アプリケーションサーバが提供するものを利用します．最終的に得られるメリットはEJBと似てくるかもしれませんが，DIConはアプリケーションサーバからは独立していること，そしてアプリケーションサーバ(J2EE)の機能を細分化して選択的に利用できることなどが，EJBに対するアドバンテージではないかと思います．それがひがさんが言うところの「J2EEの解体と再構築」だと「私は」理解しています．

このように見てくると，佐藤さんは

アプリケーションサーバ with EJB vs DICon

という対比を行っているようですが，私は

アプリケーションサーバ with EJB vs アプリケーションサーバ without EJB + DICon

という対比をしています．この違いは大きいかもしれませんね．
ちょっと苦しいのは，MDBに相当するものをEJBなしで実現するのが困難っぽいというところでしょうか．JMSだけだと単なるライブラリでしかありませんからねぇ．当然WEBコンテナには乗らないし．非EJBなMOMコンテナの新標準(当然POJOベース)希望．っていうかWEBサービスがらみで何かあってもよさげ．ま，必要ならしょうがないのでMDB使いますよ．DIConからコンポーネント取ってきて呼び出すだけの単なるエントリポイントとして．ということで，S2MDBですね＞ひがさん

例えば、EJBがとても簡単に使えるようになれば、J2EEセキュリティやトランザクショナル・コンポーネントももっと一般的に、小規模な分野でも活用されると思うのです。

そうかもしれません．しかし，それがなぜEJBでなければならないのか？ということが私には疑問なのです．上でも書いたように，EJBというのは「分散オブジェクトのコンポーネント」を目指しているものです．しかし，「もっと一般的」で「小規模な分野」において，「分散オブジェクトのコンポーネント」が求められているのでしょうか？ちょっと考えにくいです．とすると，目的が合っていないもの(EJB)にどうしてそれほど期待されるのか，私にはそこが理解できないのです．
セキュリティやトランザクションなどがDIConで手軽に利用できれば，EJBは不要ではありませんか？なぜEJBでなくてはならないのですか？

しかし後者については、EJBは不要であるという「ゴール」を選んだ主語の人が、すべてをきちんと理解しているとは思えないのです。何せ、RMI+CMP+CMTだけがEJBの存在理由と思っている人が数多くいるのですから…。

ふむ．しかしながら，そういっておられる佐藤さん自身，別のMLで次のように書いておられます．

そうですね、私自身の使い方を紹介しますと、トランザクショナルなロジックはStrutsEJBで実行し、トランザクショナルである必要のないロジックは通常のActionクラスやサーブレット側（Web層）で実行する、という使い分けをしています。
EJBのメリットのほとんどはCMTとCMPにあると感じているので、トランザクションを使わないときはEJBも使わない、という具合です。

結局のところ，EJBが置かれている「現実」がこれなんじゃないでしょうか？
もちろん佐藤さんは「全てをきちんと理解して」，その上で上記のような「使い分け」にたどり着いたのだと思いますが，結果的には「すべてをきちんと理解しているとは思えない」数多くの人と似たような結論にたどり着いてしまったわけですよね？
しかし，トランザクショナルであろうがなかろうが，DIConは使う気になれるのです．ここ重要じゃないでしょうか？そして，必要になればいつでも容易にトランザクションその他を織り込むことが可能です．何も「使い分け」をする必要はありません．うん，その方がステキ！(キラッ)

「ゴールが異なれば」といいますが、アジャイルなJ2EE開発では、例えばオブジェクトのスレッド排他やTX排他はまったく不要なのでしょうか（軽量コンテナで実装済みならごめんなさい）？　ドメイン・オブジェクトのPOJOの中にsynchronizedをたくさん書いたり、ダーティ・リードが怖いから毎回DB叩いたりしているのでしょうか？

スレッド排他については，必要であればDICon with AOPでエレガントに実現可能です．まさたかさんの04/06の日記を参照願います．その元ネタはJBossAOPらしいですよ．(^^;
トランザクション排他については，まったく同じものは不要だと「私は」考えています．代わりに「トランザクショナルな分散キャッシュ」を考えています．これは，同じ目的を達成する異なった実装手段であると思っています(違っていたらごめんなさい)．それを実現すべく，とあるシステムでTANGOSOL社のCoherenceという製品を評価する予定でしたが，残念ながら，お客様が同業他社と合併することになり，システム統合を優先するということで白紙になってしまいました．無念だ．Coherenceについては，私の03/25の日記を参照願います．

それと、セキュリティ・コンテキストはどうでしょう。ユーザIDやアクセス権は全部引数で受け渡ししている？　それとも毎回顧客テーブルから引っ張るのでしょうか？

全部引数で受け渡す？そんなことを避けるためにこそ，DIConは有効です．セキュリティに関しては，さらにAOPを組み合わせて宣言的に扱う方が格好いいと思いますが．
残念ながらSpringでもS2でも，現時点ではセキュリティがらみのAspect等は提供されていないようです．しかし，HttpServletRequest を ThreadLocal にでも設定し(~~これはプレゼンテーションフレームワークにより実装が異なりそう~~Filter使えばいいだけですね)，それを参照するようなセキュリティマネージャを用意すれば，getUserPrincipal()/isUserInRole(String) を必要とするクラスに自在にDependency Injectionできます．さらに，セキュリティマネージャと連携するAspectを用意すれば，セキュリティも宣言的に扱えます．自分で作ってもたいしたことはないと思いますが，希望すればきっとひがさんが作ってくれることでしょう．ということで，S2AnA(Authentication and Authorization)ですね＞ひがさん

ですから、これらをひとつづつDIコンテナに実装していけば、それはもはやAPサーバです。CICS→Tuxedo→CORBA→EJB→DIコンテナと、歴史は繰り返しているだけなのです。

すでに述べたように，「それはもはやAPサーバです」の部分は同意しかねますが，「歴史は繰り返しているだけ」の部分は御意です．
つまりですね，今更全くの新規システムでCICSという話が出ることは滅多にないと思うのです．同じように，TUXEDOという話もまず出ないでしょう．そしてもはや，EJBという話も出なくなりつつあるというところだと思うのです．
歴史は繰り返します．一つのプラットフォームが未来永劫採用され続けるということはないのです．より洗練されたプラットフォームに取って代わられるのです(あくまで全くの新規の場合)．そしてこれからは，APサーバ + DIConの時代なんですよ！これはあくまでも個人的な思いこみなのでそこんとこよろしくです．(こぴぺ)

という感じなんですが，いかがでしょうか？私の考えていることがうまく伝わったでしょうか？
EJBを使おうとは思わないけれども，アプリケーションサーバの持つ豊富な機能は使うつもりであること，それらをソフィスティケートされた形で使うために DICon with AOP が有効だと考えていることが伝われば幸い．
これもまた同意して頂く必要も，納得して頂く必要もないのですが，「そういう考えもある」とご理解頂ければ十分というところです．

うーん，はじめの方で「文章が長かった」と反省したのに，今度の方がもっともっと長い．．．だってほら，一週間以上も頭の中であーだこーだと唸ってきたものを一気に噴き出しちゃったものですから．心より恥じる．
でも，ようやく気分すっきり♪

日記

お買い物(？)スタイル

SRS(っていうより誕生日)

はてなはてなダイアリで、PageRank の高いのを教えてください。

スタラジ補足の補足 EJBは死んでいる？