Spring 2.0でのJPA（Java Persistence API）の利用
Pages: 1, 2, 3, 4, 5, 6

上記では、Spring DAOにKodo EntityManagerFactoryがどう注入されるかを見ました。このエンティティマネージャファクトリは、DAOが自らのあらゆる永続化処理に使用するものです。今度は、Kodo EntityManagerFactoryがJNDI を通じてKodoリソースアダプタに接続します。Kodoリソースアダプタのコンフィグレーションについては、この次に見てみますが、その前に、 Springのコンフィグレーションには承知しておくべき追加項目が少しあり、すべてをまとめるのにそれが役立ちます。

Springには、WebLogic JTAトランザクションマネージャを用いてトランザクションの開始とコミットを行うように指示する必要があります。それは以下のXMLスタンザで行われます。

<bean id="transactionManager"

      class="org.springframework.transaction.jta.WebLogicJtaTransactionManager">

  <property name="transactionManagerName"

    value="javax.transaction.TransactionManager"/>

</bean>

ここで重要なことは、トランザクションタスクをWebLogic JTA実装に委譲するようにSpringに明確に指示していることです。後ほどわかるように、Kodoも、JTAトランザクションを使用するように自らの コンフィグレーションで指示されます。そこでは、MedRecサービスオブジェクトがWebLogic JTAトランザクションを開始したあと、そのトランザクションのコンテキストでDAOを呼び出すように、お膳立てされます。DAOはそのあとKodoを呼 び出し、そのKodoがデータベースに対する読み書きを既存のWebLogic JTAトランザクションの一部として実行します。

Kodoのコンフィグレーション

今回はKodo 4.0 EA4を使用しましたが、これはKodoのJPA実装のアーリーアクセスリリースです。この記事の執筆時点では、JPAを定義しているEJB 3.0仕様はまだ最終版ではなかったため、KodoがサポートしているのはJPAのプレ最終版です。Kodoは、リソースアダプタとしてWebLogic Serverにデプロイされます。そのリソースアダプタはJNDIに登録されます。リソースアダプタのコンフィグレーションは標準の ra.xml記述子ファイルで行われます。なお、このファイルは、リソースアダプタRARファイルのMETA-INFディレクトリにあります。

ra.xmlファイルを見れば、Kodoが多数のコンフィグレーションオプションをサポートしていることがわかります （これは成熟した製品のしるしです）。ただし、サンプルアプリケーションで変更する必要があったのは、それらのうちの少数のみです。では、サンプルアプリ ケーションに必要だったプロパティを以下に示しましょう。 

<config-property>

   <config-property-name>ConnectionFactory2Name</config-property-name>

   <config-property-type>java.lang.String</config-property-type>

   <config-property-value>jdbc/MedRecGlobalDataSource

   </config-property-value>

</config-property>



<config-property>

   <config-property-name>ConnectionFactoryName</config-property-name>

   <config-property-type>java.lang.String</config-property-type>

   <config-property-value>jdbc/MedRecGlobalDataSourceXA

   </config-property-value>

</config-property>



<config-property>

   <config-property-name>TransactionMode</config-property-name>

   <config-property-type>java.lang.String</config-property-type>

   <config-property-value>managed</config-property-value>

</config-property>



<config-property>

   <config-property-name>LicenseKey</config-property-name>

   <config-property-type>java.lang.String</config-property-type>

   <config-property-value>XXXXXXXXXXXXXXXXXXXX</config-property-value>

</config-property>



<config-property>

   <config-property-name>PersistentClasses</config-property-name>

   <config-property-type>java.lang.String</config-property-type>

   <config-property-value>

      com.bea.medrec.domain.Patient,com.bea.medrec.domain.Address,

      com.bea.medrec.domain.User,com.bea.medrec.domain.Physician,

      com.bea.medrec.domain.Prescription,com.bea.medrec.domain.Record,

      com.bea.medrec.domain.Group,com.bea.medrec.domain.VitalSigns

   </config-property-value>

</config-property>

Kodoにはまず、データベースとやり取りできるように、JDBCデータソースのJNDI位置を指示する必要があります。実際、Kodoは2つの データソースのことを知っている必要があります。すなわち、1つはトランザクションタスクを処理するためのデータソースで、もう1つは非トランザクション タスクを処理するためのものです。これは、Kodoはデータベースにアクセスして、グローバルトランザクションの一部であってはいけないようなタスクを実 行することが時々あるからです。もう見当がついているかもしれませんが、ConnectionFactoryNameプロパティと ConnectionFactory2Nameプロパティはこの目的に使用されるものです。各プロパティの値は、WebLogicデータソースのJNDI 名です。ConnectionFactory2Nameは必ず、自らの接続をグローバルJTAトランザクションに参加させないようなデータソースを参照す るようにしてください。

Kodoはまた、アプリケーションがJTAにより管理されるトランザクションを使用するのか、それともローカルトランザクションを使用するのかを 知っている必要があります。MedRecのサービスBean（トランザクションを制御するもの）はJTAを使用するようにコンフィグレーションされるの で、TransactionModeプロパティの値はmanagedに設定します。さらに、Kodoのライセンスをリソースアダプタファイルでコンフィグ レーションするほか、アプリケーションで使用する永続クラスをリストアップする必要もあります。この目的に使用されるプロパティは、内容が自明のものでな ければなりません。

これまでにJPA仕様を目にする機会があった方は、 persistence.xmlファイルのことをお聞き及びかもしれません。これは、JPAの永続性に関係するメタデータを記述した標準のコンフィグレーションファイルです。Kodoでは、 persistence.xmlファイルもサポートしています。ただし、アプリケーションサーバ環境でKodoの最新アーリーアクセス版を使用する場合は、 persistence.xmlファイルには、リソースアダプタのコンフィグレーションで指定されている情報のサブセットのみ記述され、ファイルはKodoエンハンサなどのツールでのみ使用されます。

ダウンロード

ダウンロードファイル（medrec-spring-jpa.zip）には、この記事で取り上げたMedRecアプリケーションのJavaおよびその他の全ソースファイルのほか、Spring 2.0とKodoのバイナリ、およびそれらの付属物が含まれています。ダウンロードするには、およそ27MBのディスク容量が必要です。

まとめ

この記事では、Spring 2.0における新しいJPAサポートの利用について詳しく見てきました。今回は、この機能を用いて、MedRecサンプルアプリケーションのデータアクセ ス層を実装し直しました。これらの新しいAPIを利用するに当たって必要な情報がこの記事に含まれていることを願っています。このテーマについてもっと詳 しく調べたいという方には、この記事に付属している実際のMedRecコードを見てみることをお勧めします。このサンプルアプリケーションコードは、 WebLogic 9.1、Spring 2.0、Kodo JPAを統合した形で併用する方法の例を示しています。

新しいJPA APIは使いやすく、直観的で、しかも柔軟性が高いことがわかりました。Java注釈は、データベースマッピングの指定に必要なメタデータの量を減らす上 で非常に有効です。JPAはまだ出来たばかりですが、ドメインモデルクラスを引き続きアプリケーションの永続化層、Web層、Webサービス層で広く使用 できるだけのパワーがあります。この再利用によって、アプリケーションアーキテクチャの飛躍的な簡略化が可能になるほか、開発者が作成する必要のある Javaクラスの数も大幅に減ります。

また、Spring 2.0のほうは、JPAを利用するデータアクセスオブジェクトを作成するための洗練された機能を提供してくれます。Springのデータアクセスアーキテ クチャのおかげで、アプリケーションの残りの部分を書き換えなくても、使用する永続化技術を別のものに切り替えることが容易になります。

関連資料

Seth WhiteはBEAのスタッフエンジニアで、 過去6年間にわたりWebLogic Serverエンジニアリングチームのメンバーとして職務に従事してきました。現在は、WebLogic Serverオープンソースチームに属しています。