WebSphere Application Server で Spring および Hibernate を使用する

WebSphere Application Server V6 および V7を使用して、オープン・ソース環境を最大限活用する

IBM® WebSphere® Application Server で Spring または Hibernate を使用することを検討している読者のために、この記事ではこれらのフレームワークをどのように WebSphere Application Server で構成しなければならないかを、さまざまなシナリオの場合で説明しています。この記事はいずれのフレームワークについても徹底的に検討することはしませんが、このようなシナリオのインプリメントを成功させるには重要な資料となります。(Spring Framework 2.5 と WebSphere Application Server V7 に対応して更新)
IBM WebSphere 開発者向け技術ジャーナルより。

Tom Alcott, Senior Technical Staff Member, IBM

Tom AlcottTom Alcott は、米国 IBM のコンサルティング IT スペシャリストです。彼は Worldwide WebSphere Technical Sales Support チームが 1998年に発足して以来のチーム・メンバーであり、その知識においてお客様よりも常に一歩先を行くよう心がけています。彼は WebSphere を担当する以前は IBMの Transarc Lab で TXSeries をサポートするシステム・エンジニアでした。これまで、メインフレーム系のシステムと分散システムの両方で 20 年間以上、アプリケーション設計と開発に従事した経験を有します。彼は WebSphere のランタイムの問題に関して、幅広く執筆と発表を行ってきています。


developerWorks
        プロフェッショナル著者レベル

Roland Barcia, Certified IT Specialist, IBM

Photo: Roland BarciaRoland Barcia は IBM Software Services for WebSphere の Consulting IT Specialist です。彼は IBM WebSphere: Deployment and Advanced Configuration の共著者の 1 人です。


developerWorks マスター著者レベル 2

Jim Knutson, WebSphere J2EE Architect, IBM

Jim KnutsonJim Knutson は、WebSphere の J2EE アーキテクトです。IBM の J2EE 関連仕様への参加責任者で、WebSphere と IBM への関わりは J2EE が登場する以前に遡ります。彼は SOA および Web サービスをサポートするためのプログラミング・モデルの展開にも従事しています。



Sara Mitchell, Software Engineer, IBM

Sara MitchellSara Mitchell は英国の Hursley にある IBM の開発研究所で、WebSphere Application Server のチーム・リーダーを務めています。



Dr. Ian Robinson, STSM, WebSphere Transactions Architect, IBM

Ian RobinsonDr. Ian Robinson は IBM シニア・テクニカル・スタッフ・メンバーで、IBM WebSphere Application Server のトランザクション・アーキテクトを務めています。12 年以上、分散トランザクション・システムの設計およびインプリメントに携わる彼は、IBM CICS サーバーおよび ComponentBroker CORBA サーバーにも取り組みました。OASIS Web Services Transaction テクニカル委員会の共同議長でもあり、J2EE Activity Service (JSR 95) では仕様リーダーとして WS-Transaction 仕様の作成に加わりました。英国の University of Exeter で1986年と 1989年にそれぞれ、物理学の理学士号と博士号を取得しています。



Tim Ward, Software Engineer, IBM

Author photoTim WardはIBMハーズレー研究所のソフトウェア・エンジニアです。彼は現在アジャイル・プロジェクトに積極的に参画しており、WebSphere Application Server の開発者です。英国のケンブリッジ大学で理論物理学を学び、MSciを取得しています。



2009年 11月 (初版 2006年 9月 20日)

はじめに

一般的に Spring と呼ばれる Spring Framework は、J2EE™ 環境をよりアクセスしやすくすることを目的としたオープン・ソース・プロジェクトです。Spring が提供する単純な Java™ オブジェクト用のフレームワークは、ラッパー・クラスと XML 構成によって Java オブジェクトがJ2EE コンテナーを利用できるようにします。Spring が目標としているのは、開発の生産性とランタイム・パフォーマンスを高めると同時に、テスト範囲とアプリケーション品質を改善することにより、プロジェクトに大きなメリットをもたらすことです。

Hibernate はオープン・ソースのパーシスタンス・フレームワーク兼クエリー・フレームワークで、POJO (Plain Old Java Object) とリレーショナル・データベース・テーブル間のオブジェクト・リレーショナル・マッピングを行うとともに、データを照会して取得する機能を提供します。

これらのフレームワークを使用することから得られるメリットを見いだすことに興味を持っている組織は数多くありますが、IBM ではこの 2 つのフレームワークを実際に使用するカスタマーに、WebSphere Application Server を使えば同じ結果を堅牢かつ信頼性の高い方法で達成できることを知ってもらいたいと望んでいます。この記事では、Spring またはHibernate をできるだけ円滑に使い始められるようにするため、これらのフレームワークを WebSphere Application Server と併せて使用する方法、そしてさまざまな使用事例でのベスト・プラクティスを説明します。


Spring の使用方法

Spring は一般的に軽量コンテナー環境として説明されていますが、開発を単純化するためのフレームワークと表現したほうが適切かもしれません。Rod Johnson の依存性注入デザイン・パターンに関する資料を基に Interface21 が開発した Spring Framework は、スタンドアロン・アプリケーションでもアプリケーション・サーバーでも使用できます。そのメイン・コンセプトは、依存性注入とアスペクト指向プログラミングを使用して、開発、テスト、実動への遷移を単純かつ円滑に行えるようにするというものです。

もっともよくある Spring の使用シナリオの 1 つは、単純な Java Bean クラスを使用してビジネス・ロジックを構成し、制御するというものです。Spring Bean を使ったアプリケーションを構築するには Spring の資料に記載されている情報があれば十分で、WebSphere に固有のことは何もありません。以降のセクションでは、WebSphere Application Server で Spring を使用する場合のシナリオをいくつか紹介します。この記事のアドバイスに従って Spring アプリケーションを開発すれば、WebSphere Application Server または WebSphere Application Server Network Deployment 環境で何の支障もなく動作するアプリケーションが完成するはずです。

明記していない限り、この記事に記載する情報はあらゆるプラットフォームでの WebSphere Application Server バージョン 6.0.2.x, 6.1.x および 7.0.x に関連します。

表示層についての考慮事項

このセクションでは、Web ベースの表示層で Spring を使用する場合に考慮する必要がある事項を説明します。

  • Web MVC フレームワーク

    Spring の Web MVC フレームワークは、これまでの既存のフレームワークに代わるものです。WebSphere Application Server が直接提供、使用、そしてサポートしている Web MVC フレームワークには、JSF (JavaServer Faces) および Struts があります。これらの Web フレームワークに Spring を統合する方法は、Spring の資料に記載されています。WebSphere Application Server では上記にあげた、IBM で提供するのは WebSphere Application Server 付属のフレームワークを対象とした製品サポートのみです。

  • Portlet MVC フレームワーク

    Spring は Portlet MVC フレームワーク (Spring Web MVC フレームワークと非常によく似ています) も提供しており、WebSphere Portal V6.0 と WebSphere Application Server V6.1 ポートレット・コンテナーの両方で動作します (Spring ポートレットのサンプル・セットについては、Spring Portlet MVC を参照)。ポートレットを WebSphere Application Server V6.1 ポートレット・コンテナーで実行するには、追加で Web アプリケーションを作成して、ポートレットのレイアウトと統合機能を定義する必要があります。ポートレット統合機能のタグ・ライブラリーの使用方法については、WebSphere Application Server インフォメーション・センターおよび記事「Introducing the portlet container」を参照してください。レンダリングをする場合、一般的には JSF をポートレットと組み合わせて使用します。Spring、Hibernate、JSF、および WebSphere Portal を組み合わせる方法については、記事「Configuring Hibernate, Spring, Portlets, and OpenInSessionViewFilter with IBM WebSphere Portal」を参照してください。

データ・アクセスについての考慮事項

このセクションでは、トランザクション内でデータにアクセスする Spring Bean の構成に関する考慮事項を説明します。

Spring フレームワークは基本的に Spring Bean をコンテナー管理層でラップしますが、J2EE 環境では、この作業を基礎となる J2EE ランタイムに委任します。以下に、Spring Framework が WebSphere Application Server ランタイムに適切に委任 (そして統合) するように Spring Bean を構成する方法を説明します。

  • WebSphere Application Server 内に構成されたデータ・ソースへのアクセス方法

    WebSphere Application Server は、アプリケーション・サーバーの実行環境内で使用されるリソースを管理します。JDBC データ・ソースなどのリソースにアクセスする必要がある Spring アプリケーションは、WebSphere 管理対象リソースを使用しなければなりません。そのための手順は以下のとおりです。

    1. 開発中に、リソース参照を使ってWAR モジュールを構成します。例えば、以下のように設定します。

      <resource-ref>
      	<res-ref-name>jdbc/springdb</res-ref-name>
      	<res-type>javax.sql.DataSource</res-type>
      	<res-auth>Container</res-auth>
      	<res-sharing-scope>Shareable</res-sharing-scope>
      </resource-ref>
    2. EJB JAR ファイルには、データ・ソースにアクセスする必要のあるそれぞれの EJB に同じ resource-ref を宣言します。

    3. 次に、以下のようにしてデータ・ソース・プロキシー Bean を Spring アプリケーション構成内で宣言して、WebSphere 管理対象リソース・プロバイダーを参照させます。

      <bean id="wasDataSource" 
          class="org.springframework.jndi.JndiObjectFactoryBean">
      	<property name="jndiName" 
      		value="java:comp/env/jdbc/springdb"/>
      	<property name="lookupOnStartup" 
      		value="false"/>
      	<property name="cache" 
      		value="true"/>
      	<property name="proxyInterface" 
      		value="javax.sql.DataSource"/>
      </bean>

      このプロキシー Bean でデータ・ソースにアクセスすると、モジュールに構成された参照を使ってデータ・ソースが参照されるので、データ・ソースが WebSphere Application Server によって正しく管理されることになります。jndiName プロパティー値は、java:comp/env/ パターンと resource-ref に宣言された res-ref-name を連結した値であることに注意してください。

      その他の方法として、 Spring 2.5 以降では、 <j2ee:jndi-lookup/> を使用したアプローチも利用できます。jndiName プロパティーと、resouce-refの中で宣言された res-ref の実際の値が一致していることをご確認ください。また、resource-ref=”true”プロパティーが設定されていることにもご注意ください。

      <jee:jndi-lookup id=" wasDataSource "
      	jndi-name="jdbc/springdb"
      	cache="true"
      	resource-ref="true"
      	lookup-on-startup="false"
      	proxy-interface="javax.sql.DataSource"/>
    4. Spring アプリケーションが必要に応じてデータ・ソース・プロキシー Bean を使用できるようになります。

    5. アプリケーションを WebSphere Application Server にデプロイするときには、リソース・プロバイダーとリソース・データ・ソースを通常の方法で構成して、Spring アプリケーションのリソース参照で使用できるようにします。モジュールのデプロイメント記述子内で宣言されたリソース参照は、デプロイメント中にアプリケーション・サーバーの構成済みデータ・ソースにバインドされます。

  • JDBC ネイティブ接続の使用方法

    Spring は、さまざまな JDBC 操作でネイティブ JDBC リソースとの対話が必要なときにネイティブ接続にアクセスするメカニズムを提供します。この機能を使用するのは Spring の JdbcTemplate クラスで、このクラスに NativeJdbcExtractor クラスが設定されている場合です。NativeJdbcExtractor クラスが設定された場合、WebSphere Application Server で使用される Spring は常にネイティブ JDBC 接続までドリルダウンします。これによって、以下の WebSphere のサービス品質の機能と利点が使用されなくなります。

    • 接続の処理追跡と再関連付け
    • 接続の共有
    • トランザクションへの関与
    • 接続プール管理

    もう一つの問題は、WebSphereNativeJdbcExtractor クラスは内部 WebSphere アダプター・クラスに依存するという点です。これらの内部クラスは、WebSphere Application Server バージョンによって異なる場合があり、将来変更された場合には、この機能に依存するアプリケーションが動作しなくなる可能性があります。

    NativeJdbcExtractor クラス (WebSphereNativeJdbcExtractor など) をインプリメントして使おうとしても、WebSphere Application Server でサポートしていないため、このクラスのインプリメンテーションが必要となるシナリオは避けなければなりません。代わりの手段として、WebSphere Application Server の WSCallHelper クラスを使用してデータ・ソースの非標準ベンダー拡張機能にアクセスしてください。

  • Spring でのトランザクションの使用方法

    WebSphere Application Server は、トランザクションの処理とリソース・プロバイダーへの接続管理を行うための堅牢でスケーラブルな環境を提供します。JDBC、JMS、および Java Connector リソース・アダプターとの接続は、グローバル・トランザクションが使用されているかどうかに関わらず、WebSphere Application Server によって管理されます。グローバル・トランザクションがないとしても常にランタイム・コンテキストが存在し、このコンテキスト内でリソースとプロバイダー間のすべての接続にアクセスできます。WebSphere Application Server ではこのランタイム・コンテキストをローカル・トランザクション内包 (LTC) 範囲と呼びます。グローバル・トランザクションがないときには常に LTC があり、グローバル・トランザクションまたは LTC のいずれかがある場合にはリソース・アクセスは常にランタイムによって管理されます。トランザクション・コンテキスト管理の保全性 (そして、その結果としてトランザクション・リソースの適切な管理) を確実にするため、WebSphere Application Server はアプリケーションとの javax.transaction.TransactionManager インターフェースも WebSphere Application Serverにデプロイされたアプリケーション・フレームワークも公開しません。

    Spring のトランザクション制御のもとでリソースの更新を行うには、プログラムによる形式と宣言による形式の両方を含め、いろいろな方法があります。宣言による形式には、Java 注釈形式と XML 記述子形式の両方があります。Spring 2.5 を WebSphere Application Server V6.0.2.19 または V6.1.0.9 以降で使用すると、Spring の宣言型トランザクション・モデルの完全なサポートを利用できます。Spring 2.5 には、WebSphere Application Server 向けの新しい PlatformTransactionManager クラスがあります。WebSphereUowTransactionManager と呼ばれるこのクラスは、WebSphere Application Server がトランザクション・コンテキスト管理のためにサポートする UOWManager インターフェースを利用します。WebSphere Application Server の UOWManager クラスによってトランザクション区分を管理すると、リソース・プロバイダーにアクセスする際には常に確実に、適切なグローバル・トランザクションあるいは LTC コンテキストが使用可能になります。一方、Spring の以前のバージョンで使用していた内部 WebSphere インターフェースは、Web および EJB コンテナーのリソース管理機能に影響があり、アプリケーションでの使用をサポートしていません。そのため、コンテナーは不明な状態のままになり、場合によってはデータの破壊を引き起こす恐れがありました。

    Spring 2.5 以降の宣言型トランザクション区分は、WebSphere トランザクション・サポートに対して以下の宣言を使用する WebSphere Application Server でサポートされます。

    <bean id="transactionManager"
    	class="org.springframework.transaction.jta.WebSphereUowTransactionManager"/>

    この宣言を参照する Spring Bean は、例えば以下のような標準 Spring 依存性注入によってトランザクション・サポートを使用します。

    <bean id="someBean" class="some.class">
    	<property name="transactionManager" >
    		<ref bean="transactionManager"/>
    	</property>
    ...
    </bean>
    <property name="transactionAttributes">
    	<props>
    		<prop key="*">PROPAGATION_REQUIRED</prop>
    	</props>
    </property>

    代わりに、 Spirng 2.5 以降では、 Spring の AspectJ サポートを使用することができます。以下の例では、アプリケーションのさまざまな箇所に <tx:advice/> を適用することができます。この例では、 “get” で始まる全てのメソッドにPROPAGATION_REQUIREDを指定し、 ”set” で始まる全てのメソッドに PROPAGATION_REQUIRES_NEW を指定しています。その他のメソッドは全て、デフォルトのトランザクション設定を使用します。

    <tx:advice id="txAdvice" transaction-manager="transactionManager">
       <tx:attributes>
          <tx:method name="get*" propagation="REQUIRED" read-only="true" />
          <tx:method name="set*" propagation="REQUIRES_NEW" />
          <tx:method name="*" />
       </tx:attributes>
    </tx:advice>

    <aop:config/> タグにより、 MyService クラスに定義された実行オペレーションに、これらの設定が適用されます。

    <aop:config>
       <aop:pointcut id="myServiceOperation" 
          expression="execution(* sample.service.MyService.*(..))"/>
       <aop:advisor advice-ref="txAdvice" 
          pointcut-ref="myServiceOperation"/>
    </aop:config>

    トランザクション設定を宣言するその他の方法として、 Spring のアノテーション・ベースのトランザクション・サポートを使用する方法があります。これには Java 5 以上が必要となるため、 WebSphere Application Server V6.0.2.x では使用できません。

    Spring.xml構成に次の記述を追加します。

    <tx:annotation-driven/>

    トランザクション属性を必要とするメソッドは、@Transactional アノテーションを使用することができます。

    @Transactional(readOnly = true)
    public String getUserName()
    { ...

    @Transactional アノテーションは、public メソッドにしか使えないことに注意してください。

    WebSphereUowTransactionManager は、以下の Spring トランザクション属性のそれぞれをサポートします。

    • PROPAGATION_REQUIRED
    • PROPAGATION_SUPPORTS
    • PROPAGATION_MANDATORY
    • PROPAGATION_REQUIRES_NEW
    • PROPAGATION_NOT_SUPPORTED
    • PROPAGATION_NEVER

    org.springframework.transaction.jta.WebSphereUowTransactionManager を提供しない以前の Spring のバージョン、あるいは com.ibm.wsspi.uow.UOWManager を提供しない V6.0.2.19 または V6.1.0.9 より前のバージョンの WebSphere Application Server では、以下の Spring 構成によって WebSphere Application Server でのトランザクション・サポートが有効になります。

    <bean id="transactionManager" 
    	class="org.springframework.transaction.jta.JtaTransactionManager">
    		<property name="autodetectTransactionManager"value="false" />
    </bean>

    上記の構成がサポートするのは限られたトランザクション属性で、PROPAGATION_NOT_SUPPORTED と PROPAGATION_REQUIRES_NEW は含まれません。Spring クラスの org.springframework.transaction.jta.WebSphereTransactionManagerFactoryBean も同じく PROPAGATION_NOT_SUPPORTED と PROPAGATION_REQUIRES_NEW の機能を必要とし、サポートされていない内部 WebSphere Application Server インターフェースを使うため、WebSphere Application Server では使用すべきではありません。

  • Spring JMS の使用方法

    JDBC データ・ソースにアクセスする場合と同じく、JMS 宛先にアクセスすることを意図された Spring アプリケーションは必ず WebSphere 管理対象 JMS リソース・プロバイダーを使用しなければなりません。Spring の JndiObjectFactoryBean を ConnectionFactory のプロキシーとして使用するという同じパターンによって、JMS リソースを適切に管理することができます。

    JMS メッセージの送信や非同期 JMS メッセージの受信には、 JMSTemplate を使用することができます。これには、JNDIおよび動的解決を使用したSpringの動的宛先解決の機能が含まれます。
    以下は、 ConnectionFactory用の宛先参照の構成例です。この参照は、アプリケーションのデプロイ時に、アプリケーション・サーバーの JNDI ネームスペースに保管された ConnectionFactoryを指すようにマップされます。ConnectionFactoryはメッセージングを実行するよう要求され、Spring JMSTemplateの中に注入されます。

    <resource-ref>
          <res-ref-name>jms/myCF</res-ref-name>
          <res-type>javax.jms.ConnectionFactory</res-type>
          <res-auth>Container</res-auth>
          <res-sharing-scope>Shareable</res-sharing-scope>
    </resource-ref>

    これで、アプリケーション内にConnectionFactory用のJNDI名が定義され、lookupしたり、JMSTemplate内に注入したりすることができるようになります。

    <jee:jndi-lookup id="jmsConnectionFactory" jndi-name=" jms/myCF "/>
    
    <bean id="jmsQueueTemplate" 
             class="org.springframework.jms.core.JmsTemplate">
      <property name="connectionFactory">
          <ref bean="jmsConnectionFactory"/>
       </property>
       <property name="destinationResolver">
          <ref bean="jmsDestResolver"/>
       </property>
        ...
    </bean>
    
    <!-- A dynamic resolver -->
    <bean id="jmsDestResolver" class=" 
          org.springframework.jms.support.destination.DynamicDestinationResolver"/>
    
    <!-- A JNDI resolver -->
    <bean id="jmsDestResolver" 
    	class=" org.springframework.jms.support.destination.JndiDestinationResolver"/>

    ランタイム時に、JMSTemplate は、(アプリケーションのリソース参照の中で構成された)JNDI名、もしくは、WebSphere Application Server内に構成された宛先の管理名に基づいた”動的解決”によって、宛先を決定します。例えば、JMSのmyQueue キューの場合、jms/myQueueというJNDI参照に紐付けられます。

    JNDI解決:
    jmsTemplate.send("java:comp/env/jms/myQueue", messageCreator);

    動的解決:
    jmsTemplate.send("myQueue", messageCreator);

    J2EEのメッセージ・ドリブンBean (MDB) の代替として、Springでは、インバウンドのJMSメッセージを非同期に処理するためのメッセージ・ドリブン POJO モデルを提供しています。DefaultMessageListenerContainer クラスのみが、JMSキューからjavax.jms.MessageListener を実装したPOJOへのメッセージを管理します。
    WebSphere Application Server 環境では、WorkManagerTaskExecutor クラスも指定する必要があります。これは、DefaultMessageListenerContainerクラスが、サーバー管理のスレッド・プールに委任することを意味しています。DefaultMessageListenerContainer はまた、上記で述べたように、WebSphereUowTransactionManager を使用したサーバーのトランザクション管理として構成されている必要があります。

    <bean id="messageListener" class="sample.ExampleMessageListener" />
    
       <bean id="msgListenerContainer"
          class="org.springframework.jms.listener.DefaultMessageListenerContainer">
          <property name="connectionFactory" ref="jmsConnectionFactory" />
          <property name="destination" ref="jmsQueue" />
          <property name="messageListener" ref="messageListener" />
          <property name="transactionManager" ref="transactionManager" />
          <property name="taskExecutor" ref="myTaskExecutor" />
       </bean>
    
       <bean id="myTaskExecutor"
          class="org.springframework.scheduling.commonj.WorkManagerTaskExecutor">
          <property name="workManagerName" value="wm/default" />
       </bean>
    
       <bean id="transactionManager"
          class="org.springframework.transaction.jta.WebSphereUowTransactionManager" />
    
       <jee:jndi-lookup id="jmsConnectionFactory" jndi-name="jms/CF1" />
    
       <jee:jndi-lookup id="jmsQueue" jndi-name="jms/jmsQueue" />

    このメッセージ・ドリブン POJOモデルも使用できますが、ワークロード管理や高可用性を提供するWebSphere Application Server構成内でJ2EEのメッセージ・ドリブン Bean (MDB) を直接使用する方が推奨されます。その他のSpring JMS MessageListenerContainer型は、管理されていないスレッドを開始するだけでなく、Java EE 環境ではアプリケーションが呼び出すべきでない JMS API を使用する可能性があるので、サポートされないということに注意してください。

  • Spring での JPA の使用方法

    EJB 3.0 仕様では、ポータブルで永続化されたJava エンティティーを提供するための手段として、JPA (Java Persistence API) を定義しています。WebSphere Application Server V7 および WebSphere Application Server V6.1 EJB 3 Feature Pack のいずれも、 EJB 3 と JPA の実装を提供しています。また、WebSphere Application Server V6.1上で、JPAのApache OpenJPA 実装を使用することもできます。(「参考文献」を参照)。Spring を JPA実装とともに使用する場合は、Spring の JPA ヘルパー・クラス (org.springframework.orm.jpa パッケージ内) を使うよりも、JPA を直接使用するほうをお勧めします。

    WebSphere Application Server V6.1 以降がサポートする JPA アプリケーション管理対象エンティティー・マネージャーのトランザクション・タイプは、JTA またはリソース・ローカルのいずれかになります。JTA エンティティー・マネージャーが使用するのは、アプリケーション・サーバーの基礎となる JTA トランザクション・サポートです。この場合、標準的な J2EE 手法または上記の Spring の宣言型トランザクション・モデルのいずれかを使用してトランザクション区分を定義することができます。

    JPA を使用するデータ・アクセス・オブジェクト (DAO) は、アプリケーションで使用する JPA EntityManager のパーシスタンス・コンテキストを定義する persistence.xml を使ってパッケージ化されます。例えば JNDI 名が「java:comp/env/jdbc/springdb」のデータ・ソースを使う JTA エンティティー・マネージャーの persistence.xml は、以下のようにセットアップすることができます。

    <persistence 
       xmlns="http://java.sun.com/xml/ns/persistence"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
       http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd" version="1.0">
    	<persistence-unit name="default" transaction-type="JTA">
    	<provider> org.apache.openjpa.persistence.PersistenceProviderImpl </provider>
    	<jta-data-source> java:comp/env/jdbc/springdb </jta-data-source>
    	<properties>
    		<property name="openjpa.TransactionMode" value="managed" />
    		<property name="openjpa.ConnectionFactoryMode"value="managed" />
    		<property name="openjpa.jdbc.DBDictionary" value="db2" />
    	</properties>
    	</persistence-unit>
    </persistence>

    openjpa.TransactionMode および openjpa.ConnectionFactoryMode プロパティーを「managed」に設定することで、OpenJPA はトランザクションと接続の管理を WebSphere Application Server に委任します。DAO は上記で説明した Spring の宣言型トランザクション区分を使用することもできます。

    JPA EntityManagerのアノテーションを使用した注入も可能です。この方法は、標準JPAと同一の方法となります。

    @PersistenceContext
    private EntityManager em;

    EntityManagerの注入を有効にするためには、SpringのXML構成に以下のXMLコードが必要です。

    <!-- bean post-processor for JPA annotations -->
    <bean class="org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor"/>

    Spring はこの XML ファイルに定義された EntityManagerFactory のいずれかから EntityManager を生成します。複数の EntityManagerFactory が存在した場合は生成に失敗します。以下の方法の1つ(必ず1つのみ)を使用して EntityManagerFactory を作成してください。

    • Spring の基本構成を使用する
      <bean id="entityManagerFactory"
            class="org.springframework.orm.jpa.LocalEntityManagerFactoryBean">
         <property name="persistenceUnitName" value="default"/>
      </bean>
    • Springの拡張構成を使用する
      <bean id="myEmf" 
      	class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
        <property name="dataSource" ref="ds"/>
      </bean>
      
      <jee:jndi-lookup 
          id="ds" 
          jndi-name="jdbc/ds" 
          cache="true" 
          expected-type="javax.sql.DataSource"
      />

    もちろん、 WebSphere Application Server V7 および WebSphere Application Server V6.1 EJB 3 Feature Packでサポートされている純粋な EJB 3 を使用しても、アノテーションと JPA のメリットは得られます。どちらの場合も、以下に示すように、 JPA の API を使用してEntityManagerFactory を生成することができます。このアプローチは、EJB 3以外の環境にはお勧めできません。なぜなら、生成されたEntityManager が適切に管理されない可能性があるからです。しかしながら、EJB 3 環境をお持ちならば、Springの環境と JPAの構成を分離するためにこのこのアプローチを取ることができます。

    <bean id="myEmf" 
       class="javax.persistence.Persistence" 
       factory-method="createEntityManagerFactory" >
      <constructor-arg type="java.lang.String" value="default"/>  
    </bean>
  • IBM JDK 6

    WebSphere Application Server V7 は IBM JDK 6 上で稼動しており、V2.2.5 より前のバージョンの Spring Framework を使用することができません。これは Spring の問題によるもので、こちらのJIRA に記述されています。

  • HttpSessionContextIntegrationFilter と forceEagerSessionCreation の使用について

    WebSphere Application Server のアプリケーションを保護するためには、必ず WebSphere Application Server のセキュリティー・メカニズムを使用してください。Spring の セキュリティー・フィルターである HttpSessionContextIntegrationFilter を使用した場合には、注意すべき、問題となるシナオリがあります。

    HttpSessionContextIntegrationFilter は、WebSphere Application Server のサーバー・サイドのアプリケーション・コードが呼ばれた後に実行されます。例えば、レスポンス・データを返す index.jsp が呼ばれた後に、フィルターが実行されます。その結果として、Springフィルターの中のセッション作成が呼ばれた時には、既にレスポンスがコミットされ、HTTPヘッダーは既に返されているということになります。

    HTTPレスポンスに Set-Cookie ヘッダーを追加する必要があり、また、レスポンスは既に送り返されているために、(WebSphere Application Server のような) Java EE に準拠したコンテナーは、IllegalStateException をスローし、 Set-Cookie に失敗する可能性があります。この例外は、少なくともSpring セキュリティーの幾つかのバージョンにおいては抑えられており、結果として、後にNullPointerExceptionを引き起こす可能性があります。そして、こうなってしまうと、実際に何が起こっているのかを判断することが非常に難しくなってしまいます。

    このような問題を避けるためには、Spring 構成の中の、 HttpSessionContextIntegrationFilter エントリーのForceEagerSessionCreation オプションを true に設定します。

    <property name="forceEagerSessionCreation" value="true"/>

統合と管理についての考慮事項

  • JMX と MBean

    Spring の JMX MBean が WebSphere Application Server V6.1 以降でサポートされるのは、WebSphere Application Serverのコンテナー・マネージャー MBeanServer に登録されている場合のみです。サーバー・プロパティーが指定されていなければ、MBeanExporter が自動的に実行中の MBeanServer を検出しようとします。そのため、アプリケーションを WebSphere Application Server で実行している場合には、Spring フレームワークはコンテナーの MBeanServer を指定することになります。

    MBeanServerFactory を使って MBeanServer をインスタンス化してから、それを MBeanExporter に注入することはできません。さらに、Spring の ConnectorServerFactoryMBean または JMXConnectorServer でインバウンド JMX ポートをオープンしてローカルの MBeanServer をクライアントに公開することは、WebSphere Application Server ではサポートされません。

    Spring の JMX MBeanは、バージョン 6.1 より前の WebSphere Application Server ではサポートされません。

  • WebSphere Application Server でのSpring MBean の登録

    WebSphere Application Server の MBean が、以下のように登録されている場合、WebSphere Application Server の MBean は javax.management.ObjectName で識別されます。

    WebSphere:cell=99T73GDNode01Cell,name=JmxTestBean,node=99T73GDNode01, process=server1, type=JmxTestBeanImpl

    これはすなわち、MBean を登録解除するときには、MBean の単純な名前ではなく、「完全修飾」名を使って指定しなければならないことを意味します。そこで最善の方法となるのは、org.springframework.jmx.export.naming.ObjectNamingStrategy をインプリメントすることです。ObjectName インスタンスの作成をカプセル化するこのインターフェースは、MBeanExporter が Bean を登録するときに ObjectName を取得するために使います。その一例が Spring Framework フォーラムに記載されているので参照してください。登録する Bean には ObjectNamingStrategy インスタンスを追加することができます。これにより、アプリケーションがアンインストールされるときに MBean を正しく登録解除することができます。

    <bean id="exporter" class="org.springframework.jmx.export.MBeanExporter"
       lazy-init="false">
    <property name="beans">
    	<map> <entry key="JmxTestBean" value-ref="testBean" /> </map>
    </property>
    <property name="namingStrategy" ref="websphereNamingStrategy" />
    ...
    </bean>
  • MBean の ObjectName と通知

    WebSphere Application Server では MBean に完全修飾 ObjectName を使うため、通知を使用するにはその ObjectName を省略せずに定義しなければなりません。この記事を書いている時点では、オープン JIRA を使うことで Spring Bean 名を代わりに使用でき、通知を簡単に使用できるようになります。

    <bean id="exporter" class="org.springframework.jmx.export.MBeanExporter" 
       lazy-init="false">
    	<property name="beans">
    		<map>
    		  <entry key="JmxTestBean" value-ref="testBean" />
    		</map>
    	</property>
    	<property name="namingStrategy" ref="websphereNamingStrategy" />
    	<property name="notificationListenerMappings">
    		<map>
    		  <entry key="WebSphere:cell=99T73GDNode01Cell, name=JmxTestBean,
    			node=99T73GDNode01, process=server1, type=JmxTestBeanImpl">
    			  <bean class="client.MBeanListener" />
    		  </entry>
    		</map>
    	</property>
    </bean>
  • System z の multicall/unicall に関する制約事項

    Spring では MBean 記述子内でプラットフォーム固有のフィールドの仕様が許可されないことから、Spring JMX は WebSphere Application Server V6.1 のマルチ SR サーバーで機能しますが、デプロイメント・オプションに制約があります。WebSphere Application Server は unicall ストラテジーをデフォルトで設定するので、要求を実行するように呼び出されるのは (1 つの未確定 SR 内にある) 1 つの MBean インスタンスだけです。一部のシナリオではこれで十分ですが、アプリケーションで multicall メソッドと unicall メソッドの組み合わせを宣言可能でなければならない可能性のほうが高いので、おそらくは集約ロジックが必要になります。

  • スケジューリングおよびスレッド・プーリング

    Spring にはスケジューリング作業に使用できる多数の TaskExecutor クラスがありますが、WebSphere Application Server が作業を非同期で実行するためにサポートする Spring の TaskExecutor は唯一、WorkManagerTaskExecutor クラスだけです。このクラスは WebSphere Application Server が管理するスレッド・プールを適切に使用し、構成済み WorkManager に委任します。その他の TaskExecutor インプリメンテーションは、管理されていないスレッドを開始する可能性があります。

    WorkManager を WebSphere Application Server 管理コンソール内にセットアップするには、Resources => Asynchronous beans => Work managers にナビゲートします。ここで、リソースの JNDI 名を Spring 構成ファイル内で使用して WorkManagerTaskExecutor を定義できます。次の例では、WebSphere Application ServerのDefaultWorkManager JNDI名、wm/default を使用しています。

    <bean id="myTaskExecutor" 
    	class="org.springframework.scheduling.commonj.WorkManagerTaskExecutor">
      <property name="workManagerName" value="wm/default" />
    </bean>
  • クラス・ローダー

    Spring と WebSphere Application Server はどちらも複数のオープン・ソース・プロジェクトを使用しますが、共通で使用しているプロジェクトのバージョンが常に同じであるとは限りません。そのため、Spring の依存関係をアプリケーションの一部としてパッケージ化し、以下に説明するようにサーバーをセットアップして競合を防ぐ必要があります。このようにしないと、クラス・ローダーがランタイムやアプリケーションに適切なバージョンをロードしない可能性があります。通常、不適切なバージョンをロードすることにより例外が発生し、ログにはクラスのバージョンの不一致 (ClassCastExceptions、または java.lang.VerifyErrors) として記録されます。

    一例として、JCL (Jakarta Commons Logging) を使用する場合があります。JCL をアプリケーション用に構成したり、アプリケーション・サーバーで提供している JCL とは異なるバージョンの (例えば、アプリケーション・コードに組み込まれた) JCL を使用するには、WebSphere Application Server で専用の構成を行う必要があります。デプロイしたアプリケーションが汎用技術の組み込みバージョンを使用するように構成する方法については、「Integrating Jakarta Commons Logging」を参照してください。また、サポート Web サイトで WebSphere Application Server V6.x 製品での組み込み JCL の構成方法に関する更新を見逃さないようにしてください。これは競合の単なる一例です。その他にも、アプリケーション用 JDOM や JavaMail の特定バージョンで競合が発生する可能性があります。WebSphere Application Server の JAR ファイルを以降のバージョンや他のバージョンの JAR ファイルもしくは他のパッケージに置き換えることは、サポートされていません。

    WebSphere Application Server での Spring ユーザーの悩みの種となるもう一つのクラス・ローダーの問題は、Spring がリソースをロードする方法です。リソースにはメッセージ・バンドルなどが含まれる場合があり、クラス・ローダー階層と、その階層内でリソースを特定するためのポリシーによって、共通の名前を持つリソースが予期しない場所で見つかることがあります。この問題を解決するには、WebSphere Application Server のクラス・ローダー・ビューアーを使用します。このビューアーとさまざまなバージョンの共通ライブラリーを組み合わせるには、アプリケーションでリソース名を固有の名前に変更しなければならない場合があります。

    Spring フォーラムで James Estes が説明した例では、EAR ファイルの中に、EJB プロジェクトと Web プロジェクトがパッケージされています。説明されたソリューションは、spring.jar ファイルを WEB-INF/lib と EAR の最上位レベルの両方に追加してから WEB プロジェクトのクラス・ローダー・ポリシーを PARENT LAST に設定し、最初に WEB-INF/lib でバージョン検索を行うようにすることです。EJB プロジェクトは EAR 内のバージョンを使用します。

設計についての考慮事項

Spring Framework が提供するインフラストラクチャー・サービスの一部は、標準ベースのアプリケーション・サーバー・ランタイムが提供するサービスと重複します。さらに、基礎となる J2EE アプリケーション・サーバーからの Spring フレームワーク・インフラストラクチャーの抽象化は必然的に、アプリケーション・サーバー・ランタイムのサービス品質 (セキュリティー、作業負荷管理、高可用性など) を弱めてしまいます。そのため、WebSphere Application Server にデプロイされたアプリケーションでの Spring Framework の使用は、アプリケーションの設計段階で慎重に検討して、WebSphere Application Server が提供するサービス品質を無効にしないようにしなければなりません。他に推奨事項が設けられていない場合は、オープン・スタンダードをベースにアプリケーションを開発し、さらに将来デプロイメントする際の柔軟性を持たせるために、WebSphere Application Server が提供するサービスを直接使用することをお勧めします。

  • 管理されないスレッド

    Spring のシナリオには、管理されないスレッドが作成されてしまうものがあります。管理されないスレッドは、WebSphere Application Server には認識されないため、Java EE のコンテキスト情報にアクセスできません。さらに管理されないスレッドには、WebSphere Application Server の認識外でリソースを使用する、管理者によるスレッド数とリソース使用率の制御なしで存在する、アプリケーション・サーバーのグレースフル・シャットダウンやリソースの障害からの回復を遅らせるなどの問題があります。アプリケーションでは、管理されないスレッドを開始する以下のようなシナリオを使用してはいけません。


    • registerShutdownHook

      Spring の AbstractApplicationContext やそのサブクラスを使用することは避けてください。public メソッドには registerShutdownHook と呼ばれるものがあります。このメソッドはスレッドを作成して、そのスレッドを Java VM に登録し、シャットダウン時にこのスレッドを実行して ApplicationContext を終了させます。アプリケーションでこの事態を回避するには、WebSphere コンテナーから受信する通常のライフ・サイクルの通知を利用して、ApplicationContext の終了を明示的に呼び出してください。

    • WeakReferenceMonitor

      Spring には EJB コンポーネントの簡易開発に便利なクラスが用意されていますが、これらのクラスはクリーンアップのために管理されないスレッド (WeakReferenceMonitor が使用) を発生させるため、注意が必要です。

  • スケジューリング

    Spring は多数のスケジューリング・パッケージを提供 (または統合) しますが、Spring スケジューリング・パッケージのなかで WebSphere Application Server が管理するスレッドを使って動作するのは CommonJ WorkManager だけです。その他のパッケージ (quartz やJDK Timer など) は管理されないスレッドを開始するため、使用しないでください。


Hibernate の使用方法

Hibernate は、POJO 対応のオープン・ソース・パーシスタンス・フレームワークで、XML 構成ファイルを使用して POJO とリレーショナル・データベース・テーブル間のオブジェクト・リレーショナル・マッピングを行います。Hibernate フレームワークは、データ・パーシスタンスのためにアプリケーションによって呼び出されるデータ・アクセス抽象化レイヤーです。さらに、 Hibernate では Java クラスからデータベース・テーブル (および Java データ型から SQL データ型) へのマッピング、ならびにデータ照会機能と検索機能も提供します。Hibernate は必要な SQL 呼び出しを生成するとともに、結果セットの処理とオブジェクト変換を行います。

Hibernate は、OpenJPA のように JPA (Java Persistence API) 仕様を実装します。これは、Java EE 5 では必須となっています (Hibernate の使用方法に関する developerWorks の記事については、「参考文献」を参照してください)。

使用方法のシナリオ

以下に、WebSphere Application Server および WebSphere スタック製品での使用方法に関して考えられるいくつかのシナリオを説明します。これらのシナリオは単なる例なので、推奨されるシナリオだとは思わないでください。

  • WebSphere Application Server データ・ソースの使用

    Hibernate が WebSphere Application Server からデータベースに接続するには、Java EE (以前は J2EE として知られる) 仕様で指定されているように、リソース参照を使用する必要があります。これにより、WebSphere Application Server は接続プーリング、トランザクション・セマンティクス、そして分離レベルに適切な動作を行うことができます。WebSphere Application Server からデータ・ソースを取得するように Hibernate を構成するには、hibernate.connection.datasource プロパティー (Hibernate 構成ファイルに定義) を、モジュールのデプロイメント記述子に定義されたリソース参照 (java:comp/env/jdbc/myDSRef など) を参照するように設定します。例えば、以下のように設定します。

    <property name="hibernate.connection.datasource">
    	java:/comp/env/jdbc/myDSRef
    </property>

    Web アプリケーションの場合の Java EE リソース参照は、WAR ファイル・レベルで定義します。つまり、コンテナー内のすべてのサーブレットと Java クラスがリソース参照を共有します。EJB モジュール内では、リソース参照は個別の EJB コンポーネントで定義します。そのため、多数の EJB コンポーネントが同じ Hibernate 構成を使用する場合、それぞれの EJB は各 EJB コンポーネントで同じ参照名を定義しなければなりません。これによって問題が発生する場合がありますが、それについてはもう少し後で説明します。

    データ・ソースを構成した後、Hibernate を正常に機能させるための作業の 1 つとして必要なのは、トランザクション・サポートを正しく構成することです。

  • トランザクション・ストラテジーの構成

    Hibernate がトランザクションで正常に実行するためには、肝心な 2 つの部分を構成する必要があります。1 つは、トランザクション制御を定義する hibernate.transaction.factory_class です。もう 1 つは hibernate.transaction.manager_lookup_class で、これはトランザクション同期の登録メカニズムを定義し、パーシスタンス・マネージャーがデータベースと変更を同期する必要がある場合、トランザクション終了時にそのことをパーシスタンス・マネージャーに通知するようにします。トランザクション制御については、コンテナー管理構成と Bean 管理構成の両方がサポートされます。Hibenate を WebSphere Application Server で使用する場合には、Hibernate.cfg.xml で以下のプロパティーを設定してください。

    • コンテナー管理トランザクションの場合

      <property name="hibernate.transaction.factory_class">
      	org.hibernate.transaction.CMTTransactionFactory
      </property>
      <property name="hibernate.transaction.manager_lookup_class">
      	org.hibernate.transaction.WebSphereExtendedJTATransactionLookup
      </property>
    • Bean 管理トランザクションの場合

      <property name="hibernate.transaction.factory_class">
      	org.hibernate.transaction.JTATransactionFactory
      </property>
      <property name="hibernate.transaction.manager_lookup_class">
      	org.hibernate.transaction.WebSphereExtendedJTATransactionLookup
      </property>
      <property name="jta.UserTransaction">
      	java:comp/UserTransaction
      </property >

    jta.UserTransaction プロパティーは、WebSphere コンテナーから UserTransaction オブジェクト・インスタンスを取得するためのファクトリー・クラスを構成します。

    hibernate.transaction.manager_lookup_class プロパティーは、WebSphere Application Server V6.x 以降による WebSphere プラットフォーム、および WebSphere Business Integration Server Foundation V5.1 以降でサポートされます。このプロパティーは、WebSphere Business Integration Server Foundation V5.1 および WebSphere Application Server V6.0 で導入された ExtendedJTATransaction インターフェースを使用するように Hibernate を構成します。この WebSphere ExtendedJTATransaction インターフェースは、JTA 1.1 仕様によって Java EE 5 で正式化されたパターンを確立します。

  • サポートされないトランザクション構成

    Hibernate の資料では、WebSphere Application Server バージョン 4 およびバージョン 5 製品で実行するトランザクション・ストラテジー構成について説明していますが、これらの構成は内部 WebSphere インターフェースを使用するため、これらのバージョンではサポートされません。サポートされる Hibernate のトランザクション構成は上記に説明したものだけです。つまり前述したように、Hibernate の使用は WebSphere Business Integration Server Foundation V5.1 および WebSphere Application Server Version 6.x 以降でしかサポートされません。

  • WebSphere Application Server 環境での Hibernate の使用パターン

    Hibernate をWebSphere Application Server で使用する場合は、Hibernate のセッション毎要求パターンと長期会話パターンの両方を使用できます。私たちの意見としては、セッション毎要求のほうがスケーラビリティーに優れていますが、使用しているアプリケーションにはどちらが適切かを判断するのはお客様の役目です。

    • 複数の分離レベル

      複数のリソース・ユーザーが既存の接続を共有できるようにすると、共有可能な接続によって WebSphere Application Server のパフォーマンスが向上します。ただし、共有可能な接続と複数の分離レベルの両方が必要な場合は、それぞれの接続構成に個別の resource-ref と Hibernate セッション・ファクトリーを定義してください。共有された接続の分離レベルを変更することは不可能であるため、 hibernate.connection.isolation プロパティーを使用して共有可能な接続に分離レベルを設定することもできません。接続の共有に関するポリシーと制約事項についての詳細は、「Sharing connections in WebSphere Application Server V5」を参照してください (この記事は概して、WebSphere Application Server V5 での共有接続の使用についてのみ説明していますが、接続の共有に関するアドバイスは、V6.x 以降にも適用されます)。

    • Web アプリケーション

      HttpSession オブジェクトでは、Hibernate 長期会話セッションの使用と保管が可能ですが、Hibernate セッションはアクティブなインスタンスを保持するため、これを HttpSession に保管してもスケーラブルなパターンにはなりません。その理由は、セッションをシリアライズするか、あるいは追加のクラスター・メンバーに複製しなければならないためです。HttpSession には切断されたオブジェクト (10KB から 50KB の小さいサイズである限り) を保管し、更新が必要になったときに新規 Hibernate セッションにオブジェクトを再び関連付けることをお勧めします。HttpSession は、キャッシングではなく、ブックマークに使用するのが最適です。HttpSession でのメモリー使用率を最小化する方法については、「Improving HttpSession Performance with Smart Serialization」に記載されています。HttpSession をキャッシュとして使用する代わりに、次のセクションで説明する ObjectGrid や DistributedObjectCache などの WebSphere データ・キャッシング技術を使用することを検討してください。

    パフォーマンスに優れたスケーラブルなアプリケーションに関するベスト・プラクティスについては、『Performance Analysis for Java Websites』がお勧めの一冊です。

この記事の発行時点では、WebSphere Application Server を併用した Hibernate のクラスター対応キャッシュの動作はまだ決定されていません。このキャッシュの使用がサポートされるかどうかはまだ未定なので、詳細は説明しません。分散 キャッシュが必要な場合は、WebSphere の 2 つの分散キャッシュ・インプリメントのうちのいずれかを用いた hibernate.cache.provider_class プロパティーを使用して、 org.hibernate.cache.CacheProvider をインプリメントするクラスを作成することを検討してください。

  • 第 2 レベル・キャッシュの統合

    Hibernate セッションは、作業単位のスコープを表します。Hibernate セッションのライフ・サイクル期間中は、セッション・インターフェースがパーシスタンスを管理します。パーシスタンスの管理は通常、マッピングされたエンティティー・クラスの対象インスタンスの認識または状態を維持し、単一のスレッドに対して有効なインスタンスの第 1 レベル・キャッシュを保持することによって行われます。このキャッシュは、作業単位 (セッション) が完了すると消去されます。クラスター全体を含め、SessionFactory のすべてのセッションで第 2 レベル・キャッシュが共有されるように構成することもできます。ただし、Hibernate でのキャッシングによって、対処しなければならない問題が発生します。まず、データベースに対する外部の変更やクラスター対応キャッシュを使用しないクラスター全体でキャッシュが整合していることを確実にするための取り組みは行われていません。また、その他の層 (データベースなど) が先にキャッシングを行って、Hibernate キャッシュの値を最小限にする可能性もあります。このような問題はアプリケーションの設計段階で慎重に検討しなければなりませんが、この記事の範囲外です。

    Hibernate には、複数の事前定義されたキャッシュが付属しています。これらのキャッシュについては、Hibernate のキャッシュに関するページに記載されています。読み取り専用データの場合は、メモリー内のキャッシュで十分です。ただし、アプリケーションがクラスター化されているためクラスター対応キャッシュが必要な場合は、ローカルの読み取り専用キャッシュでは足りません。分散キャッシュが必要な場合は、WebSphere に用意されている以下の分散キャッシュ・インプリメンテーションのいずれかを使用することをお勧めします。これらのキャッシュも、Hibernate で第 2 レベル・キャッシュとして使用できます。


  • WebSphere Enterprise Service Bus および WebSphere Process Server での Hibernate の使用

    WebSphere Process Server と WebSphere Enterprise Service Bus (ESB) は、SOA のアセンブリーおよびプログラミング・モデルとして、サービス・コンポーネント・アーキテクチャー (SCA) およびサービス・データ・オブジェクト (SDO) を利用します (SCA およびSDO についての詳細は、「参考文献」を参照してください)。SCA コンポーネントは Java EE コンポーネントではないためリソース参照を持ちませんが、代わりにサービスとアダプターを利用してシステムに接続します。Java SCA コンポーネントをビルドする際にはリソース参照を使用できないので、SCA コンポーネントは Hibernate を直接使用できません。

    この場合、Hibernateパーシスタンスをある種のファサードで隠す必要があります。それには 2 つの方法があります。


    • ローカル EJB セッション・ファサードを作成して、Hibernate パーシスタンスをラップします。このセッション・ファサードは、Hibernate エンティティー POJO とサービス・データ・オブジェクトをマッピングするアダプター・ロジックを提供します。これにより、統合開発者は EJB インポートを使用してセッション・ファサードを呼び出し、次にこれを対応するサービス品質 (QoS) と密結合した形で呼び出すことができます。
    • EJB Web セッション・ファサードを作成して、Hibernate パーシスタンスをラップします。これにより、統合開発者は Web サービス・インポートを使用して、パーシスタンス用 Web サービスを呼び出すことができます。ただし、現在 SCA はデータ型に SDO のみを使用するため、POJO から SDO へのコンバーターを作成しなければなりません。詳細についてはこの記事の範囲外ですが、図 1 に、両方のパターンを使用したビジネス・プロセスを示します。
    図 1. サンプル・ビジネス・プロセス
    サンプル・ビジネス・プロセス
  • WebSphere Application Server V6.1 での Hibernate の JPA API

    Hibernate の JPA サポートは JPA 標準パーシスタンス用で、専有 Hibernate API の代用として適しています。Hibernate の JPA インプリメンテーションは Java SE 5 ベースのランタイムを必要とするため、WebSphere Application Server V6.1 以降でのみ稼動します。この記事を発行する時点で、Hibernate の JPA サポートは WebSphere System z または iSeries プラットフォームでは稼動しません。Hibernate の資料には、Hibernate の JPA インプリメンテーションでアプリケーションをパッケージ化してデプロイする方法が記載されています。

  • 相互運用または移植が不可能な機能

    JPA 仕様のセクション 3.2.4.2 では、相互運用性および潜在的な移植性の問題が発生する可能性のあるシナリオを説明しています。これは、遅延ローディング (つまり、@Basic(fetch=LAZY)) と分離オブジェクトの併用に関連します。分離オブジェクトをセッションに再びマージすると、JPA はオブジェクトを検査して、変更された値が 1 つでもあればその値でデータ・ストアを更新します。ただし、データ・オブジェクトは単純な POJO です。分離されたときに POJO 状態の一部がロードされていないと、再びマージするときにそれが変更としてみなされてしまう可能性があります。正しく機能させるためには、ベンダーがランタイム固有のシリアライズの手法をインプリメントしなればなりません。その結果、相互運用が不可能になり、セマンティクスも移植できなくなります。Back to top


製品およびお客様技術サポート

ユーザーにとって当然気掛かりなのは、オープン・ソースを使用するプロジェクトのサポートと、これを使用することによって、ライセンス製品に対するベンダーのサポートにどのような影響があるかという点です。IBM では、IBM WebSphere Application Server で IBM 製品以外のフレームワークを使用したいという一部のお客様の希望を踏まえ、IBM WebSphere Application Server でもっとも信頼性の高い動作環境の作成を進めるための情報を提供しています。IBM は、お客様がインストールしたオープン・ソース・コードおよびアプリケーション・フレームワークは、それがアプリケーションの一部または共有ライブラリーの一部としてバンドルされているかには関わらず、アプリケーション・コードの一部であると考えます。お客様はこの情報を十分に生かしてオープン・ソース・プロジェクトを使用することによって、IBM の製品サポートと技術サポートを引き続き利用できるという強い安心感を持って IBM 製品を使用することができます。WebSphere 製品でこれらのフレームワークを使用している際に問題が発生した場合、IBM は確実に その問題の原因が WebSphere 製品にはないようにするために最善を尽くします。

お客様には、この記事に記載する推奨事項をよく読み、以下の重要な点を理解した上で、Spring または Hibernate などのフレームワークを安全に IBM 製品上で使用することが求められています。

  • これらのフレームワークは、WebSphere Application Server で許容される使用方法でのみ使用してくだい。具体的に言うと、内部の製品インターフェースを使用するフレームワークは使用してはならないということです。残念ながら、多くのオープン・ソース・フレームワークでは、注意深く構成しないと内部の製品インターフェースが使われてしまいます。WebSphere での回避事項として明示されているシナリオは使用しないようにしてください。
  • オープン・ソース・フレームワークでは、お客様が確実に、WebSphere Application Server で使用しているフレームワークに対応するソース・コードとバイナリーを理解し、使用しなければなりません。
  • オープン・ソース・コミュニティー、またはオープン・ソース・コミュニティーに参加しているパートナーから、フレームワークの修正サービスを受けることをお勧めします。

IBM のサポートおよび方針についての詳細は、IBM Support Handbook および WebSphere Application Server Support Statement を参照してください。

この記事に記載する推奨実施例に従えば、WebSphere Application Servers をオープン・ソース環境で使用する際に大いに役立ちますが、オープン・ソース・コンポーネントが WebSphere Application Server の動作やその他のコンポーネントの動作に影響する可能性がある場合をすべて網羅しているわけではありません。オープン・ソース・コードのユーザーは、ライセンス、サポート、および技術上の問題が生じないよう、すべてのコンポーネントの仕様をもう一度読むことを強くお勧めします。

この記事では、「サポートする」または「サポートされる」という言葉は一貫して、記載されている使用方法では IBM 記載の機能のみを使用するということを示しています。この記事の著者たちは、フレームワークの使い方が、ドキュメント化されている製品の使い方と確実に一致するように、フレームワークを構成して使用する方法についてのアドバイスを提供するよう、最善を尽くしています。しかしこの記事は Spring または Hibernate のサポートを保証するものでも、提示するものでもありません。


まとめ

Spring Framework は瞬く間に人気を伸ばしました。開発者たちが気に入っているのは、J2EE 開発時間を短縮し、ユニット・テストを簡単にする使いやすいインターフェースと XML ベースの構成です。フレームワーク自体も同じく急速な成長を続けており、Web サイトには数多くのサブプロジェクトが一覧にされています。あらゆるソフトウェアと同様に、アプリケーションに組み込むことによってどんなメリットがもたらされるのか、そして同じ最終結果を達成するのに代わりとなる手段や優先される手段があるのかどうかを見極めることが重要です。明らかに、Spring には WebSphere Application Server 内にすでに組み込まれている機能と重複するものがあるため、サーバーにデプロイされるアプリケーションが、この追加のフレームワーク・コード層を使用するのは望ましいことではありません。ただし慎重に使用することによって、Spring の使い勝手の良い開発機能の多くを WebSphere Application Server の堅牢な統合エンタープライズ・サポート機能と併せて活用し、エンタープライズ・アプリケーションを素早く開発して IBM の業界きっての J2EE アプリケーション・サーバーにデプロイすることが可能になります。

Hibernate は、リレーショナル・データベースに格納されたエンティティー・データへのオブジェクト・リレーショナル・マッピングを行うパーシスタンス・フレームワークのひとつであり、 WebSphere Application Server とともに使用することできます。ただし、それには十分気を配って問題のあるシナリオを回避することが条件です。特に、Hibernate が確実に内部 WebSphere Application Server インターフェースを使用することがないようにしなければなりません。この記事に記載した推奨事項に従えば、よくある問題を回避して、Hibernate をWebSphere Application Server にデプロイされたアプリケーションのパーシスタンス・フレームワークとして使用することができます。


謝辞

Keys Botzum 氏、Paul Glezen 氏、Thomas Sandwick 氏、Bob Conyers 氏、Neil Laraway 氏、そして Lucas Partridge 氏のこの記事に対するコメントおよび協力を感謝します。

参考文献

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=WebSphere, Open source
ArticleID=278366
ArticleTitle=WebSphere Application Server で Spring および Hibernate を使用する
publish-date=11202009