オブジェクト・リレーション・マッピングと永続化のためのオープンソースのJavaフレームワークであるApache Cayenneが、リモートオブジェクトの永続化およびORMモデリングツールをサポートした。このフレームワークのバージョン3.0は5月にリリースされている。Cayenneのリモートオブジェクト永続化機能によって、JavaオブジェクトをWebサービス経由でクライアントから永続化することができる。このフレームワークは、データベースのリバースエンジニアリングおよび生成、およびVelocityを元にしたクラス生成エンジンをサポートする。
InfoQは、CayenneチームのAndrus Adamchik氏(VP)とAristedes Maniatis氏(プロジェクト・マネジメント・コミッティのメンバー)に会い、フレームワークの新バージョンの機能および将来のロードマップについて話を聞いた。
InfoQ: Apacheには、既にOpenJPAというプロジェクトがあるのに、他のORMプロジェクトがなぜ必要なのですか？
実際のところ、Cayenneはより歴史のあるプロジェクトです。最初のリリースは2002年の7月にリリースされ、Apacheに2006年に移りました。何はともあれ、Apacheでは、似たようなゴールをもったプロジェクトが重複することはよくあることで、エンドユーザに選択の余地を提供できます。それぞれのORMは、異なった注力分野をもち、似たような問題にも異なったソリューションを提供します。選択肢があることによって、全ての製品がより強化されていくのです。
InfoQ:Cayenneは、JPA 2.0仕様をサポートしていますか?
いいえ。JPAの最初のバージョンに対しては、実装に莫大な時間を費やしました。しかし2008年にこの方針を捨て去ることに決めました。作業量が莫大になるだけでなく、Cayenneがより革新的なアプローチをとる際の足かせになるのです。私たちは、ユーザから強い支持をえています。また開発者は、CayenneのクリーンなAPIと、付加的に提供している機能を選択してくれると信じています。これらのことは、厳格な仕様に準拠することと両立することはできないのです。しかし、Cayenneは、ほぼ全てのJPAのコンセプトをサポートしています。そのなかには、EJBQLの実行も含まれます。
InfoQ: CayenneフレームワークはJPA仕様に含まれない機能も提供しているのですか？
はい。Cayenneは数多くの革新的な機能を提供しています。例えば次のようなものです。(1) ROP (Remote Object Persistence:リモートオブジェクト永続化)。この機能によって、リモートのJavaアプリケーションが、データベースに直接アクセスするのではなく、CayenneのWebサービスにアクセスすることができるようになります。複数のアプリケーション層にまたがるビジネスロジックを分離しつつ、それぞれの層が同一の永続化APIを利用できるようになります。(2) 汎用オブジェクトマッピング。この機能により、コンパイル時ではなく、実行時に動的にマッピングを行うことができるようになります。(3)ネストしたObjectContext。また、Cayenneには、同じチームによって開発されている「モデラー」アプリケーションも存在し、データベースとJavaの階層を目に見えるかたちでより簡単に表現できるようになっており、これは、常に最新のフレームワークのバージョンと同期をとっています。
InfoQ:Cayeneeフレームワークでは、開発者や運用者が永続化やキャッシュの詳細をみるために、どのような監視の仕組みをサポートしていますか。
Cayenneは、JPAと同じようにコールバック/リスナメカニズムをサポートしています。また、詳細なログ取得の仕組みも組み入れられています。下層のスタックを監視するためのJMX拡張は、すでにプロトタイプが作成されており、次のバージョン3.1に含まれることになるでしょう。また、Cayenneのクエリキャッシュは差し替え可能なため、ユーザは自分たちが利用するキャッシュプロバイダのイベントメカニズムを利用して、Cayenneとは独立したキャッシュのJMXモニタリングを実装することも可能です。私たちが知っている範囲でも、いくつかのプロジェクトで、この方式がとられています。
InfoQ:将来のバージョンの一部となる、新しい依存性の注入(DI)コンテナ機能について教えてください。
Cayenne DIコンテナは小さく(約35Kというサイズ)、XML不要で、使いやすく、外部ライブラリへの依存がない(Cayenneにさえ依存していません)という特徴があります。このDIコンテナの目的は、Cayenne実行環境をロードおよび管理することですが、それ以外の面ではできる限り控えめに実装しています。つまり、SpringやGuiceなどをアプリケーションが利用した場合でも干渉しないのです。Cayenneを制御し、ユーザにCanynneの挙動をカスタマイズするための拡張ポイントを提供するために存在しているのです。
実装面では、Google Guiceの影響を受けています。依存性はコンストラクタもしくはフィールドのアノテーションで設定されます。一般的なDIの機能はほとんどサポートしています。クラスやインスタンスやインスタンスプロバイダのバインディング、MapやListに対するバインディング、起動時に複数のモジュールを一つのコンテナに統合、スコープのバインディング、十分な機能をもったバインディングAPI、怠惰なインスタンス化などです。Guiceと違い、我々のDIはスコープライフサイクルの考えを取り入れています。これはCayenneのようなフレームワークには、とても重要なのです。DIコンテナに管理されたオブジェクトは、メソッドにアノテーションをつけることによって、スコープイベントを受け取ることができます。もっとも使われるケースとしては、スコープの最後にリソースの一部を開放することがあげられます。ユーザは独自のスコープを簡単に作成でき、カスタムイベントを設定できます(Webリクエストスコープなど)。DIのjarファイルの小ささを考えると、非常に多数の機能が含まれています。唯一欠けている重要なDI機能は、動的プロキシと割り込みです。この機能を将来追加するかもしれません。
InfoQ:新機能や機能拡張という観点での、Apache Caynneプロジェクトのロードマップを教えてください。
近頃行われている議論や仕事が取り入れられていきます。ジェネリクスを完全にサポートした新しいクエリAPIや、JPAスタイルのEJBQLQueryとCayenneの元々あったSlectQueryの統合、複数のマッピングプロジェクトを一つのランタイムにマージできるようにしてモジュール化をより推し進める、データベースごとの独自性の扱うための現在進行中の仕事、コアサービスをリファクタリングしてDI機能をとりいれ、機能拡張をしやすくする(これは、先に述べたJMX拡張もふくんでいます)、Cayenne Modelerを拡張しより強力で簡単に利用できるようにする、などです。
とはいっても、すべてのオープンソースプロジェクトがそうであるように、ユーザの要求によって、どの機能が開発されるか、現存の開発者のリソースでどの分野の開発を前進させるかが決まってきます。