J2EE 1.3の登場とともに、「J2EEといえばJava版CGI」だった時代が終わります。非同期メッセージングJMSをはじめ、汎用リソースコネクタJCA、セキュリティプロバイダJAAS、など、新しい仕様が一気に増えました。その１年後には、さらに J2EE 1.4 にバージョンアップしますが、それに先駆けて、リソース管理JMX、XMLやWebサービス関係のJAX-API群なども、ワサワサと出てきていました。

これらの仕様群が目論んでいたのは「過去にいろんな形態で作られてきた企業システムを、J2EEサーバが統合する」ということだろうと思います。企業の中心にJ2EEサーバあり！そういう意気込みだったのではないでしょうか。

私は、J2EEサーバ製品を売る立場にいました。ですから、これらの新仕様がどういうものなのかを片っ端から調べ上げる必要がありました。お客さんから「JCAって何？」と聞かれたときに、答えられないと製品そのものが売れないからです。
システムを開発する立場（こっちが本職）としても、どういうときにどの仕様を活用できるか、事前に検証しておく必要がありました。さもなければ、J2EEサーバを導入することが、本当に良いことなのかどうかの判断ができません。

この当時のこの作業は、悪夢だったとしかいいようがありません。
なぜなら、J2EE1.3以降で追加された新仕様は、現場から遠い仕様ばかりだったからです。時間をかけて調べたはいいけど、「こんな機能、いつどこで使うんだよ！？」と感じてしまうような。

そして、仕様の数・規模とも莫大な量で、とてもじゃないけど追いかけきれていません。現場のSEは、お客さんの要求実現が本業です。研究で食ってるわけじゃないんだぞ！と。
それでもやはり、お客さんや営業さんから、「これって何？」みたいな問い合わせが殺到し、なんとか上っ面のセールストークでごまかしごまかし、夜な夜な英語の仕様書と格闘していたのでした。

その後も数年間、ずっとJavaの開発をつづけてきましたが、このころに出てきた仕様は、ほとんど使ったことがありません。
のちのち気づいたのですが、これらの仕様は、業務システム開発者向けの仕様ではなく、ベンダーが製品を作るための仕様でした。製品ベンダーの製品ベンダーによる製品ベンダーのための仕様。そのことに気づいたのは、ひとしきり疲れ果てたあとの話であります。

EJBのバージョンも上がりました。ここで出てきた仕様、「Local Interface」が、EJBをどん底（？）に突き落とします。
Local Inteface が導入された理由は、

ということらしいです。

この説明を受けたとき、ハタと気がつきました。

これまでは、DBアクセスは盲目的にEJBを使ってきましたが、ローカルにあるのなら、EJBを使う必要が全くナイ。なぜなら、EJBは「分散オブジェクト」ですから。

でも、O-Rマッパーの機能を使いたければ、EntityBeanをつかわなければなりません。だとすれば、Local Interface という自己矛盾も、なおいっそう複雑になった配置記述子も、だまって受け入れなければなりません。
EJBの問題は、「分散オブジェクト」と「データ永続機能」のまったく違う２つの機能を、長い間、分離せずにいたことです。今期リリースされたEJB3.0では、この点が改められたそうですが、トキすでに遅し、になってはいまいか・・・

こういったJavaの肥大化は、開発者に「もうJavaなんて使いたくない。」と思わせるには十分な出来事だったかもしれません。でもやはり、IT企業に属している限り、Javaからは（なぜか）逃れられません。
だとすれば、「どうやったら楽に使いこなせるか？」を真剣に考える必要がありました。次回はそのときの話にしようと思います。