Entity Beanとは
昨日の続きで、Entity Beanの話をしましょう。永続性に関しては、Entity Bean以外にもJDOのようなオプションがあると書きました。でも、Entity Beanは永続性だけを目的としたBeanではありません。ここでは、永続性以外の側面からEntity Beanのことを考えてみます。
永続性以外でEntity Beanを使いたい理由で思いつくのは、プログラマが排他制御をしたくないとか*1、永続フィールドごとにアクセス制御をしたいとか、Entityのメソッドごとに細かなトランザクション制御をしたいということです。これらは地味ですが、セキュリティや信頼性を向上させるには重要なものです。
これはEJBが「コンポーネント」ベースであることと無縁ではありません。マルチベンダーのコンポーネントを組み合わせてシステムを作るとき、その一つがコネクションのcloseを忘れたり、ハングしたりしたら困ります。EJBがプログラミング上、事細かにやってはいけないことを規定しているのはこのためです。つまり、コンポーネントとしての利用を抜きにしてEJBは語れません。
Enity Beanの華は「キャッシュ」にあります。Entity Beanを使う醍醐味はサーバによるキャッシュの整合性の管理です。そして、このキャッシュ管理は、クラスタリングと一緒に使ったときに輝きます。つまり、EJBサーバをクラスタリング構成にしておけば、実行時にEntityを更新したらそれは他のサーバのキャッシュに自動的に反映されるのです*2。
EJBのトランザクション管理はエレガントです。そして、トランザクションの管理をデータの側までサポートするのにEntity Beanが登場したとみるのが自然です。ただ、Entity Beanに問題があるとすれば、それはトランザクション管理の仕組みというよりも、むしろEJBというBeanの枠組みに難があったということです。よくあるEntity Bean批判はEJBの皮の問題ばかり攻めているので、このEntity Bean本来の機能*3に対し、別の有効な代替案は提示できていません。Entity Bean != O/R Mapperだからです。
