JBossDOへの想い

私は、JBossDOにオープンソースのJDO実装以上のことを期待しています。JBossDOでは、JBossPOJOの永続性を実現するための永続エンジンが先にあって、それをユーザに見せるためのAPIとしてJDOがあるのだと理解しています。

だったら、他のAPIとしてCMPがあっても、Hibernateがあっても良いはずです。JBossがJDOを選択した理由を勝手に想像すると、HibernateJCPで標準化されたものではないので現実的にJDOしか選択肢が無かったということと、JDOEnhancerがJBossAOPで実現しやすかった、ということではないかと思っています。

J2EEでJDOを使うシーンとしては、SessionBean + JDOというのが推奨されていますが、JBoss 4ではこれが「Sessionの役割をするPOJO」と「永続化されるPOJO」に置き換わるでしょう。それらの区別はメタデータ上の違いだけです。つまり、SessionやEntityという区別が(形式上は)無くなってPOJOで一本化されるということです。だから、JBossDOでは、JDOの枠だけに収まらないで、もっと常識を突き抜けたおもしろいことをやって欲しい、と願っています。

軽量コンテナについて考える

EJB用のコンテナがEJBコンテナならば、POJO*1用のコンテナが軽量コンテナです。軽量コンテナにはトランザクション、セキュリティなどのサービスを登録できます。モジュールアクセスにはJNDIを使いませんし、デプロイメントのために複雑なXMLも書きません。お手軽で高速なのがウリでしょう。

軽量コンテナは、①アプリケーションはPOJOで書く、②コンテナはスタンドアロンでも動く、③サービスはコンテナのAspectとして実現する、というのが共通する傾向です。中小規模ならスタンドアロンのコンテナでいいですし、企業アプリケーションならサーバを使えばよいでしょう。

サーバならではの機能としては、分散、クラスタリング、アプリケーション間連携、レガシーシステムとの接続、クラスローダ、デプロイメントなどがあります。JBoss 4は基本的にはサーバとしての道を歩んでいますが、JBossAOP, JBossDO, JBossJMS(Reloaded)などはスタンドアロンでも使えるように設計されています。テストは軽量コンテナ、運用はサーバのようなことができると開発者としては嬉しいですね。軽量コンテナをMock Objectのように使えるからです。

*1:Plain Old Java Object