Entity Bean批判
EJBへの批判の多くはEnity Beanへ向けられています。
Enity Beanは「分散」と「永続性」を一緒に扱っているために、「分散」が不要なユーザにとっては使いづらいというのが指摘されている問題の一つです。Entity Bean では、これらの直交した概念が一緒のコンポーネントになっている点が問題であるというわけです。
J2EEはエンタープライズシステムのアーキテクチャですから、利用ユーザの数やシステムの規模が違います。システムを無停止で動かすためには、機器の多重化が必要でしょう。そこで、コンポーネント間の「分散」連携が必要になることが多いでしょう。
しかし、実際問題として、Enity Beanをクライアントからリモートアクセスすることはほとんどありません。普通はSession Facadeパターンを使うので、Entity Beanの直接のクライアントはサーバ内のSession Beanになり、その結果、Entity BeanへのアクセスはローカルI/Fを使ったローカルアクセスだけになるからです。
「分散」が不要なのになぜローカルI/Fが必要かというと、それはコンテナがEJBへの処理をインターセプトするためです。これは、トランザクション管理もセキュリティもいらない、ただ「永続性」だけが欲しいユーザにとっては邪魔なものです。作るのは面倒、インヘリタンスもできないという制約が大きいからです。
さらに、EJBは「コンポーネント」であることを強要します。「永続性」だけが欲しいユーザにとっては「コンポーネント」化は無用です。コンポーネント化するために、XMLでデプロイメント記述子を書き、JARファイルを作り、サーバへのデプロイをするという手順が要求されます。
Entity Beanを批判する人に共通するのは、「トランザクションやセキュリティ管理などのEJBの価値は認めるが、それはSession Beanだけで十分。エンタープライズシステムでの永続性が欲しければSession Bean + O/R Mapperを使え」というものです。
さて、仮にEntity Beanを捨ててO/R Mapperを使うとして代わりに何を使うのでしょう。
- DAOを自分で作る
- ベンダーから買ってくる
システムの規模によって選択するものは異なりそうです。小規模なら1でしょうし、ある程度大規模になったら2でしょうか。1は生産性・保守性に問題がありますし、2はベンダーにlockinしてしまいますので移植性に難ありです。J2EEがこれらの問題を解決しようとしていたことを考えてみてください。
Entity Beanのメリットは、言うまでもなく、J2EE APIとして標準化されているので多くの著名なサーバベンダーによる製品があるということです。それに、J2EEで規定されているので、多くのツールのサポートが期待できます。ドキュメンテーションも豊富です。要するに、Entity Beanを使うにせよ、使わないにせよ、それぞれ一長一短があるのです。
この、2003年という時期では、J2EEのエリアでは永続性に関しては完全な解は無いと言えるでしょう。私は、近い将来の最も有力な永続性APIはJDOだと思いますが、このAPI はJ2EEに含まれていないので、現状では大手のRDBベンダーやJ2EEサーバベンダーはサポートしていません*1。しばらくの間は、永続性に関しては自分のシステムに何が一番適しているかを見極めながら最適解を探っていく必要がありそうです。
