このブログエントリは書きかけです。
「素朴なオブジェクト指向」の限界
EJBが示した一つのことは、古典的なクラスベースオブジェクト指向の限界です。つまりクラスやメソッドの組み合わせを、継承やカプセル化・多態・の枠組みで列挙していくだけでは実用上表現しきれない領域があった、ということを実証的に示したのでした。継承階層で対象を表現することの危険、特に長期的に拡張を重ねていく上で、屋上屋を重ね、融通が利かなくなっていくということも露呈しました。
また、EJBでは、「なんとかBean」という、細かく小さく役割分担を果たすクラス群に分離します。しかしながら、すこしずつ動作の違う大量のクラス種別を正確に理解し、正しい設計を行うのは並大抵のことではないでしょう。EJBは設計の敷居をあげてしまいました。もちろん「正しい設計をしろ」と言えればよいでしょう。しかし現実問題、多人数での開発でそのレベルの要員を確保するのは（EJBが普及しない以上）困難です。
本質的にも、ある特徴が、オブジェクトの属性なのか、ベースクラスの切り替えで表現されるべきなのか？の境界に関する「哲学」は、動的言語・静的言語とかとか、NO-SQLとかの台頭にも関係する深い問題だと思います。
冗長性の罠
もう一つのEJBのだめな理由は、その冗長性です。これはJava本来が持つ性質にも呼応するものです。「冗長である」ことそれ自体が致命的な問題ではありませんが、問題なのは、実装技術に言及し、それに依存してしまうことでした。
たとえば、EJBは分散処理基盤としてRMIを強く必要とするものですが、あとになって高速化のためにLocalインターフェースを導入した際に、複雑さを２倍にしてしまいました。RMIが不要な場合でもきれいに除去できませんでした。
言い方を変えると、「何をするか(what)」と「如何にするか(how)」を分離し切れなかった、ということでもあります。
「間接レイヤ」はすべてを解決しない
（略）
「標準化」の光と影
（略）
「バイナリコンポーネントの流通」は、諸悪の根源か、見果てぬ夢か？ていうか誰得？
(略）
OSSが壊したもの
（略）
EJB 2.x→3.0の差分を、現代ソフトウェア開発技術の進歩の縮図としてみたときに
（略）
