先日、SunがJavaコミュニティに向けて今後の仕様策定においては
JDO2.0(JSR-243)をEJB3.0(JSR-220)に統合していく方針である
ことを明らかにしました。EJBのEntity BeanとJDOはいずれもJava
におけるデータパーシステンスを司る役割という観点では同じです。
ですので、これらが共通化されること自体は歓迎すべきことです。
データパーシステンス、特にO/Rマッピングについては話題が盛んです。
Entity BeanのCMPも広い意味ではO/Rマッピングの一つといえるかと
思います。O/Rマッピングはボク自身も注目している技術ですが、実際
に使っていていいなぁと感じるのはやはりHibernateですね(^_^)
Java標準の技術を使えるのであればそれに越したことはないので、本来
であればJDOを使うべきなのでしょうが、ボクにとってはJDOの以下の点
が利用を思いとどまらせるポイントになっていました。
1. 各データベース製品との型マッピング方法が仕様で決められていない
これはHibernateで言えば、hibernate.cfg.xmlのDialect指定にあたる
ようなものです。元来、JDOはRDBに限定されない様々なデータソースへの
共通アクセスAPIを提供することが目的でしたので、そのような規定がない
のは当然といえば当然です。ですが、現時点ではRDBとのマッピングは少な
くとも必須ですので、プロファイルの一つとしてRDBとの型マッピング仕様
を規定しても良かったのではないかと思います。こうした実装依存の部分が
あると結局利用する側の敷居が高くなってしまいます。EJBデプロイの際に
JNDI名との関連付けが実装依存になっていたりするのはその最たる例では
ないかと思います。
2. コネクションプーリングの仕組みがない
これもクライアント/サーバー双方においての利用を想定しているJDOで
あるが故の結果だとは思います。ですが、クライアントサイドでO/R
マッピングをする機会があるかどうかちょっと疑問ですし、仕様として
プーリング用のインターフェースは提供してくれていても良かったので
はないかと思います。
3. フルスペックを装備した実装がほとんどない
実際のところはこれが最も大きな要因でしょうか。実装はいくつか存在
していますが、コレクションが扱えなかったりなど制限が目立ちます。
全ての仕様をきちんと備えたものがないと、さすがに踏み出すのは少々
ためらってしまいますね。
Hibernateの開発者であるGavin King氏も今回の動き自体は歓迎するものの
JDOに関してはやや否定的な見解を示しているようです。JDOQLがクエリー文
によるアプローチと条件文指定によるアプローチのどっちつかずのスタイル
を取っている点や関連オブジェクトを遅延ロードできなかった場合には参照
を単にnullにしているだけなので、参照オブジェクトが存在しなかったのか
遅延ロードが失敗したのかの区別がつかないといった点を問題として挙げて
います。同氏はJDOを発展させることは避けて、EJB3.0を発展させて、その
流れで将来のJDOもそこに包含させた方が良いのではないかと述べています。
ボクも個人的にはその意見に賛成です。いずれにしてもEJB3.0はパーシステンス
だけでなく、煩わしいJNDIルックアップや複数のインターフェース、DDなども
改善されることになっていますので、今後に期待しています。
