EJBには多くの荷物があります。その手荷物の一部は、それが間違った聴衆に向けられたという事実から来ています。他の部分は、最初の2つのバージョンが完全にくだらないことでした。
元のEJBバージョンを見ると、EJB開発者がEJB準拠のコンテナ内で使用できるパッケージ化されたソリューションを作成できるように設計されていました。社内ショップでは、このレベルの抽象化は不要でした。これは、サードパーティのEJBコンポーネントベンダーの繁栄する市場を作るための完璧なソリューションでした。しかし、コンテナベンダーはマーケティングに熱心であり、日々の開発の実行可能なソリューションとして製品を大量に販売していました。これは、すべてのアプリケーションコードをCOM +コンポーネントとしてビルドするのと同じです。
元のJ2EE仕様の背景については、関係するベンダーのほとんどがCORBAサーバーを持っていて、今後これらの製品を活用したいと考えました。EJB仕様は、IIOPプロトコル(実際にはIIOP上の薄い層であるJava RMI)を介して構築されました。CORBAはその複雑さのためにすでに拒否されており、EJBはCORBAに変装しただけであったため、CORBAが抱えていた多くの問題をもたらしました。実際、EJBの抽象化により、純粋なCORBA実装よりも作業が難しくなりました。
ゴムが舗装に当たると、人々はEJBのパフォーマンスがひどいことに気付きました。すべての呼び出しがリモート呼び出しであり、最初からアプリケーションを正しく起動して実行することさえ難しいため、人々はすぐに代替手段を探しました。JSPコンテナで実行されるHibernateとSpringがソリューションになりました。
EJB 3はこのアプローチを「採用」しました。しかし、それはまだ多くの利点を提供しない一般的な妥協案です。サードパーティのEJBコンポーネント市場はまだ存在しないため、EJBコンテナを使用してソリューションを構築しても意味がありません。
長い話は短い。EJB 3ですが、広大な最初の2回の反復を超える改善、それはまだコストを上回るのに十分な利益を提供していません。