ただ、J2EE アプリケーションサーバーが普及していくなかで次第に明らかになってきたのは EJB とくに CMP が思ったほど活用されないということです。CMP に関しては当初のパフォーマンスの悪さや使い勝手の悪さが尾をひいて、実力よりはるかに低く評価されている感はぬぐえないのですが、ともあれ、利用される割合が少なかったのは J2EE を普及させる側からすると誤算には違いありませんでした。

多くの試行錯誤と改善の努力の末、今、J2EE (Java EE)に画期的な API が導入されました。それが New Java Persistence API (JSR-220, 以下 JPA) です。JPA は何より政治的に大きな意義をもつ API と私は考えています。隆盛なO-Rマッパを EJB の中に取り込んだこと、そして Java EE の一部として、つまり正当な標準技術としてお墨付きを与えたこと、そして何より大きいのは、EJB と切り離して、単独で存在することを許容したということ。
特に、最後の点、JPA が、単独で Java SE と組み合わせて使用できるようになることは何より大きい。これによって、Java エンタープライズシステムのアーキテクチャーのありようは大きく変動を迎えると私は考えています。

正統な技術としてデビューしたものの存在感が今ひとつだったEJBはこれで完全にプラットフォームの「内側」の技術になるでしょう。EJB そのものが消えるのでは、と考えるのは一面的過ぎます。当初の期待ほどではないにせよ、やはり EJB は使用されており、特にツールやミドルウェアが自動生成するコンポーネントとして EJB は優れています。BPEL エディタが吐き出すコンポーネントの多くは実は、MDB のような EJB であることが多いでしょう。自動生成される Web サービスの実態も、Statless Session Bean ということになるケースが多いでしょう。ただ、ポイントは、それはもはや一般の開発者の視点からは多い隠されてしまうということです。

言葉を変えていえば、EJB は、今後 API ではなく、SPI 的な存在に転化するだろう、ということです。そして、身軽になった Java EE の主な API はより上の層、Composite Applications に比重を移すでしょう。EJB ではなく、何らかのコンテナは引き続き必要です。しかしそれは EJB2.1 以前の重量コンテナではなく、別の何かです。これらの動きは JPA の導入を契機として起こってくるのです。

Java EE (J2EE)は、非常にしたたかかな存在です。中心に君臨しながら、周縁のテクノロジーをたくみに中にとりいれ、生き残ってきたブランドです。コンテナ/コンポーネント思考、CORBA、MOM、Web サービス、DI、AOP 周辺の技術をたくみに取り入れ、先進性、存在意義を確保してきました。ただ、ブランドが生き残ることは開発者にとって、ユーザにとって決して悪いことではありません。長らく続くブランドが、信頼性を醸成していることはテクノロジーの発展、普及には非常に重要な要素だからです。
中心としての Java EE ブランド、そしてそのブランドの下側にあるテクノロジーとの二重構造、これを確定させたのが、Java EE 5、そしてその中で導入された New Java Persistence API だと思うのです。開発者にとって、好ましいテクノロジーが、安定した Java EE ブランドの元で花開く。悪いストーリーではありません。今だからこそブランドの強みに感謝し、そしてその信頼性を最大限利用すべき時なのではないでしょうか。