Spring 2.0でのJPA（Java Persistence API）の利用

Seth White著
2006年03月20日

概要

JPA（Java Persistence API）とSpring Framework 2.0が開発者の間で高い関心を呼んでいます。この記事では、Spring 2.0とJPAをBEA WebLogic Serverで使用する方法を調べます。特に、WebLogic Serverの医療記録管理サンプルアプリケーションをSpringとJPAを用いて書き換えたものについて説明します。この記事では、Springと JPAが、簡略化されたPOJOベースのアプリケーションアーキテクチャの基礎を成す強力な組み合わせになっている有様を示します。用いられる主要なテク ノロジは、WebLogic Server 9.1、Spring 2.0、Kodo JPAなどです。

はじめに

医療記録管理サンプルアプリケーション（MedRec）は、数々のテクノロジがWebLogic Serverで実際にどのように用いられているかを示す包括的なアプリケーションです。これらのテクノロジには、Webサービス、JSP、メッセージ駆動 型Bean、JDBCといったWebLogic Serverのネイティブテクノロジだけでなく、SpringやStrutsなどのオープンソーステクノロジも含まれます。

この記事では、MedRecの更新版でJPA（Java Persistence API）とSpring Frameworkがどのように併用されているかを説明します。そこでは、Spring 2.0、WebLogic Server 9.1、Kodo 4.0の併用方法を開発者に示すことが重要な目標です。この記事を読むことで、開発者はSpring 2.0でのJPAの新たなサポートだけでなく、JPAの使い方についても十分な初歩的知識を得ることができます。記事ではまた、JavaBeans （POJO）をエンタープライズアプリケーションの複数の階層で再利用するときに起こり得る難問についても議論します。この再利用こそ、Springと JPAに基づいたアプリケーションアーキテクチャの主要なメリットの1つなのです。

JPA（ Java Persistence API）に馴染みがない方々のために少し補足しておきますと、JPAは、Javaオブジェクトをデータベースに保存する方法を規定した新しい簡易APIです。JPAはEJB 2.xエンティティBeanの後継ということで、EJB 3.0（ JSR 220） の一部として開発されているところですが、J2EEアプリケーションでもJ2SEアプリケーションでも使用することができます。JPAの素晴らしいところ は、1つには、それがPOJOベースだということです。JPAではまた、Java 5.0注釈を用いて、Javaオブジェクトからリレーショナルデータベースへのマッピングの指定方法を簡略化しています。BEAでは、まもなく公開される KodoベースのオープンソースプロジェクトであるOpenJPAの設立を発表しましたが、それを待たなくても、 Kodo 4.0のアーリーアクセスリリースを使って今すぐ仕事に取りかかることもできます。

この記事ではまず、SpringにおけるPOJOとデータアクセスを概観します。その次のセクションでは、MedRecのアーキテクチャの概要を説 明したあと、MedRecのデータアクセスレイヤについてさらに詳しく説明します。そのあと、JPA永続クラスの詳細について述べ、それらが準拠すると思 われるデザインパターンについて解説します。最後に、まとめとして、SpringとKodo JPAのXMLコンフィグレーションを取り上げます。なお、MedRecの全ソースコードは、この記事でダウンロードできます。

SpringにおけるPOJOとデータアクセス

Spring Frameworkは、ビジネスコンポーネントの開発を簡略化したことでおそらく最も知られているフレームワークでしょう。Springに詳しい方であれ ば、制御の反転（IoC： Inversion of Control）とアスペクト指向プログラミング（AOP）を用いることで、Springでは開発者が強力なビジネスコンポーネントを通常の JavaBean（しばしばPOJOつまり「Plain Old Java Object」とも呼ばれる）として作成できることをご存知でしょう。

データベースへのアクセスが必要なエンタープライズアプリケーションのために、Springにはまた、永続データへのアクセスをカプセル化したデー タアクセスオブジェクト（DAO）を手軽に作成できるフレームワークも用意されています。SpringのPOJOの考え方はデータアクセスの分野にも引き 継がれており、クエリや変更の対象となるデータアクセスオブジェクトもドメインモデルオブジェクトもPOJOになり得ます。

SpringでPOJOパターンが用いられていることには、実用上の重要な利点がいくつかあります。まず第1に、ビジネスコンポーネントの場合と同 様に、POJOのおかげで、開発者にとってアプリケーションの実装に必要な作業が軽減されます。必要なコードの行数が少なくなるだけでなく、コードがまさ に標準Javaであるため、よりシンプルなものになる傾向があります。第2に、POJOを使用すると、アプリケーションコードの残りの部分（データアクセ スオブジェクトを呼び出すコード）が特定の永続化技術にまったく依存しないことになります。たとえば、アプリケーションでJDBCやJDOをそのまま使用 している場合、POJOを使えば、使用する永続化ソリューションをJPAに切り替えることは比較的容易です。

第3の利点は、ドメインモデルオブジェクト自体（MedRecでは、患者、医師、処方箋などのエンティティを表すオブジェクト）に関係します。これ らのクラスはPOJOで、（従来のEJB 2.xエンティティBeanとは異なり）特定の永続化環境に縛られていないので、アプリケーションコードでドメインモデルへのアクセスが必要とあれば、複 数の階層にわたって再利用することができます。MedRecの場合は、JSPでドメインモデルオブジェクトを使用してユーザインタフェースを表示する Web層や、ドメインモデルクラスをWebサービスメソッドのパラメータや戻り値の型に使用するWebサービス層などです。

MedRecの概要

MedRecアプリケーションのアーキテクチャの包括的概要と、そこでSpringがどのように用いられているかについては、「SpringとWebLogic Serverの統合」 （2005年9月にdev2devで公開）を参照してください。これは以前の記事で、SpringとWebLogic Serverの統合一般についてうまく説明したものです。とは言え、MedRecの問題領域にJPAがどう適合するかがはっきりわかるように、ここでも MedRecアーキテクチャについて簡単に解説しておきましょう。

図1に、MedRecのアーキテクチャ全体を示します。最上位レベルで見ると、MedRecは実際には、MedRecアプリケーションと Physicianアプリケーションという2つの独立したJ2EEアプリケーション（EARファイル）から成ります。データアクセスはすべてMedRec 部分で行われるため、ここではその部分に焦点を合わせます。

図1： MedRecアプリケーションアーキテクチャ

図1に示すように、MedRecアプリケーションはいくつかの階層に構造化されています。すなわち、Webサービスが含まれるプレゼンテーション 層、サービス層、データアクセスが含まれるインテグレーション層、そしてデータベース層です。インテグレーション層の一部を成すSpringデータアクセ スオブジェクト（DAO）は、主にサービス層のビジネスオブジェクトから呼び出されます。DAOもサービスオブジェクトも、Springアプリケーション コンテキストでコンフィグレーションされるSpring Beanです。サービスオブジェクトは、Springの宣言的トランザクションサポートを用いてトランザクションを制御します。

Pages: 1, 2, 3, 4, 5, 6

Next Page »