ise conf. l-2 was webフレームワーク連携手法 -...

2008 IBM Japan Systems Engineering Co., Ltd.

【ISE Conf. L-2】

WAS × Webフレームワーク連携手法

2008/06/06日本IBMシステムズ・エンジニアリング（株）Webインフラストラクチャー植田佳明([email protected])

2 WAS × Webフレームワーク連携手法 2008 IBM Japan Systems Engineering Co., Ltd.

この資料に含まれる情報は可能な限り正確を期しておりますが、日本アイ・ビー・エム

システムズ・エンジニアリング株式会社の正式

なレビューを受けておらず、当資料に記載された内容に関して当コンファレンスの主催者である日本アイ・ビー・エム

システムズ・エ

ンジニアリング株式会社は何ら保証するものではありません。従って、この情報の利用またはこれらの技法の実施はひとえに使用者の責任において為されるものであり、資料の内容によって受けたい

かなる被害に関しても一切の保証をするものではありません。当資料をコピー等で複製することは、日本アイ・ビー・エム

システムズ・エンジニアリング株式会社および執筆者の承諾なしではでき

ません。また、当資料に記載された製品名または会社名はそれぞれの各社の商標または登録商標です。

ご注意


目次

1. フレームワークとは？

2. フレームワークを用いたWASアプリケーション開発

3. フレームワークの歴史および今後

4. (参考)WASと連携させる上でのHints & Tips


１．フレームワークとは？

この章ではフレームワークの概要およびその利点をお話します。


基盤として稼動するフレームワーク

まず、フレームワークってなんでしょう？

基盤として再利用される汎用的なパターンや枠組み– 同様に再利用されるものにライブラリーがあるが、それよりも大きな粒度の機能/非機能要件を実現する

フレームワークとライブラリーとの違い– フレームワーク

・・・

アプリケーションの基盤となる骨組み

– ライブラリー

・・・

アプリケーションの一部を構成する要素

フレームワークという基盤の上で、ユーザー・コードやライブラリーが呼び出されて稼動する

ユーザーコード①

ユーザーコード②

呼び出し

ライブラリーライブラリー

アプリケーション実行環境（J2EEコンテナー）

呼び出し呼び出し呼び出し

アプリからライブラリーを呼び出す


J2EEシステムにおけるフレームワーク採用の利点

1.

アーキテクチャーを考慮したアプリケーション設計が容易

– 明確なレイヤー化

– プレゼンテーション層、ビジネス層、データアクセス層の分離

– デザインパターンの活用

– Service to Worker (Struts)– Factory Method (Spring)– Singletonなどなど

2.

開発生産性の向上と品質の統一

– レイヤーごとの開発、保守が容易

– コーディング量の減少

プレゼンテーション層

ビジネス層

データアクセス層

レイヤーごとの開発、保守が容易

明確にレイヤー化されたアプリケーション設計が容易

1. フレームワークが実装すべき枠組みを提供してくれる

2. フレームワークが開発方式を規定してくれる


フレームワーク採用による効果の例

短納期、低コスト化・・・– Webシステムは納期までのスピードが求められる傾向にある

– 設計や実装に費やせる時間が短い

曖昧な仕様と要求：急な仕様変更とメンテナンスへの対応に追われる・・・– 急な仕様変更を求められる場合がある

– 仕様変更に伴う影響を小さくする必要がある

開発者の技術レベルに差がある・・・– 限られたコストで技術者を雇わなければならない

– 開発にあたって習得すべき知識、技術(J2EE)が多い

フレームワークが枠組みを提供することにより、短期間での設計と実装が可能となる

フレームワークによりレイヤー間の依存性がなくなり、コードの保守性が高まる

フレームワークが複雑な処理を隠蔽してくれるため、実装をPOJOでおこなえる

システム開発でよく起こる問題への対応が容易になる



ビジネス層


フレームワークの各層ごとの位置づけテスト・フレームワーク


プレゼンテーション層のフレームワークプレゼンテーション層の役割

– ユーザーからの入出力制御

– 画面遷移のコントロール

– バリデーション･チェック

– ビジネス・ロジックを呼び出し

大きく３つのパターンに分けることができる

特徴メリット/デメリットどういうケースで有効か代表的なフレームワーク

アクション指向ユーザーのリクエストを１つ

のアクション・クラスと紐付け

て処理を記述する考え方

画面とアクションをわけることで分業

がしやすくなるアクションの再利用性を高めることが

可能となる画面遷移が複雑になると画面とアク

ションの関係がわかりにくくなる

画面デザインはデザイナー、

機能はプログラマーという担

当の切り分けが容易なため、

画面と機能の担当を分離でき

る場合に力を発揮

Struts

コンポーネント

イベント指向

画面のUI部品をコンポーネ

ント化して、スタンドアロンの

GUIアプリケーションのよう

に開発する考え方

GUIツールによる画面デザイン効率

の向上コンポーネント化によるUI部品の再

利用コンポーネント共有の容易性

コンポーネント共通チームが

共通機能を作成し、プログラ

マーがそれを再利用する、と

分業することで、大規模開発

においても設計思想の維持し

た開発がしやすい

JSF（標準仕様）Tapestry

ページ指向画面とクラスを対応させ、画

面のイベント処理をクラスの

メソッドに対応させる考え方

画面とクラスの関係がわかりやすく、

可読性が高いページ指向＝「コンポーネントイベン

ト指向」＋「画面とクラスの関係が決

まっている」

簡単な画面遷移が多いアプ

リケーション経験の少ないプログラマーが

多い

ClickTeedaWicket


ビジネス層



ビジネスロジック層のフレームワークビジネスロジック層の役割

– 業務のビジネスロジックを実装

– トランザクションの制御

大きく３つに分けることができる

特徴メリット/デメリット代表的なフレームワーク

EJB 2.1 アプリケーションのコンポーネント化を可能

とする

「トランザクションとセキュリティの管理」「分

散トランザクション」などをコンテナが提供

開発者はトランザクション制御を意識せ

ずに開発可能であり、ビジネスロジックに

集中できるただし、EJBの複雑な仕様に準拠した環

境（EJBコンテナ）でしか稼動しないため

単体テストが難しい

EJB 2.1 （標準仕様）

EJB Alternativeとし

ての軽量コンテナ（DI/AOPコンテナ）

DI / AOP という技術をベースにした（EJBよ

りも）軽量なコンテナを提供EJBのようなコンポーネントの疎結合化を

POJOベースで可能とする

ビジネス･ロジック層だけではなく、各層をつ

なぐレイヤー間接続のための機能を提供す

る

コンテナへの依存を排除したアプリケー

ション開発が可能となる（テスト容易性）EJBと同様にアプリケーション（ビジネス

ロジック）からトランザクション制御を分離

可能なので、開発者はトランザクションを

意識せずに開発可能ただし、標準仕様ではない、設定ファイル

が多くなるなどのデメリットはある

SpringSeasar2

EJB 3.0 これまでのEJBへの批判を受け入れ、軽量

コンテナの良さを取り入れたPOJOベース開発とアノテーション・ベース

設定によりEoDを実現

EJB2.1の機能を保持した上で軽量コン

テナに近いEoDを標準仕様として実現ただし、DI/AOPが適用できる範囲が限ら

れているなど、これからの改良が待たれ

る点もある

EJB3.0 （標準仕様）


ビジネス層



データアクセス層のフレームワークデータアクセス層の役割

– データソースへのアクセスする方法をDAOパターンとして提供

– オブジェクトとデータベースをつなぐO/Rマッピング機能の提供

大きく２つのパターンに分けることができる

特徴メリット/デメリット代表的なフレームワーク

SQLを隠蔽するも

の

O/Rマッピング設定をXMLへ記述す

ることで、フレームワークがSQL文を

生成

開発者が高度なSQL文の知識を持たなくとも

開発が可能

SQL文によるチューニングが難しい

HibernateToplink Essentials（→

Eclipse Link ）JPA （標準仕様）

SQLを隠蔽しない

もの

O/Rマッピング設定を外部設定ファ

イルにSQL文を記述することで実現

開発者がSQL文を記述するので、SQL文によ

るチューニングが可能となるので、SQLを詳し

く理解している技術者を活かした開発が可能と

なる

しかし、開発者がSQLへ精通していないと活用

することは難しくなる

iBatisS2Dao


ビジネス層



典型的なJ2EEアプリのままでは・・・– MVCの各層の役割分担があいまい

– コンテナーへの依存が強い

→開発と保守が面倒

→単体テストが難しい（特にEJB）

フレームワークを活用すると・・・– MVCの各層の役割分担がより明確に

– コンテナーへの依存を少なくできる

– 各層の結びつきを緩くできる

→開発、保守が楽になる

→単体テストが容易になる

フレームワークを適用するとどう変わる？

プレゼンテーション

（Controller/View）

ビジネスロジック（Model）

データベースアクセス

EJB （Entity Bean）

EJB （Session Bean）

ビジネス・ロジック（POJOとして記述）

Struts Hibernate

Spring

単体テストJUnit

Servlet/JSP

接着

剤


2．フレームワークを用いたWASアプリケーション開発

実際のWAS V6.1でのアプリケーション開発を通してフレーム

ワークの利点を見ていきます。


概要

作成するアプリケーション– ショッピングサイト

– 商品一覧画面から購入する商品を選択

– 購入すると買い物かごに入る

– 確定画面で受付け番号を発行

購入確定

WAS V6.1でフレームワークを使用しない場合と使用する場合とでアプリ

ケーションがどのように変わるかを比較する

フレームワーク使用/不使用の両方とも全く同一の機能を持つこととする


2.1 フレームワークを使用しない場合


検証環境使用技術

– J2SE 5.0 / J2EE 1.4

開発ツール– Rational Application Developer 7.0

動作環境– WebSphere Application Server Network Deployment V6.1

– DB2 V9.1


フレームワークを使用しないでアプリケーションを作成

アプリケーションの構造

-1-

CARDB

ThanksServlet

CARTBL

COUNTER

SummaryServlet

受付NO

thanks.jsp

商品一覧

index.jsp

買い物かご

summary.jsp

内容をロード

購入金額の計算

注文情報格納

①

②

③

④⑤

⑥



-2-データーベースCARDB内に2つのテーブルを作成

– CARTBL (商品の一覧を格納)

– COUNTER (確定した注文情報を格納)

表示部分は3つのJSPで作成– index.jsp ( 初にブラウザからアクセスする画面)

– summary.jsp (選択商品および合計金額表示画面)

– thanks.jsp (お礼と受付けNoの表示)

ビジネスロジックはServletで作成– SummaryServlet (合計金額を計算)

– ThanksServlet (購入情報のDBへの格納)



-問題点-

開発/保守を考慮した設計が必要

１つ１つのJSPやServletがいろいろな機

能を持ち肥大化している

各クラスが密接に関連し合っている

同じコードが様々な場所に分散している

データソースlookupトランザクション処理など

アプリケーションの変更が難しい


コードの可読性が悪い

外部の変更に弱い

DBのカラム追加など

要因要因問題点問題点


2.2 フレームワークを使用した場合


検証環境

使用技術– J2SE 5.0 / J2EE 1.4に加えて以下のフレームワークを使用

– Struts

– Spring

– Hibernate

開発ツール– Rational Application Developer 7.0

動作環境– WebSphere Application Server Network Deployment V6.1

– DB2 V9.1


Struts / Spring / Hibernateを用いて2.1で作成したアプリケーションを再構築

各フレームワークの適用イメージは以下

フレームワークの適用

CARDB

ThanksServlet

CARTBL

COUNTER

SummaryServlet

受付NO

thanks.jsp

商品一覧

index.jsp

買い物かご

summary.jsp

内容をロード


注文情報格納

StrutsSpring Hibernate


プレゼンテーション層のフレームワークとしてStrutsを使用

Strutsの適用

CARDB

ThanksServlet

CARTBL

COUNTER

SummaryServlet

受付NO

thanks.jsp

商品一覧

index.jsp

買い物かご

summary.jsp

内容をロード


注文情報格納

Struts


Strutsとは

Jakarta Project が提供するオープンソースのWebアプリケーション・フ

レームワーク– Apacheライセンスに基づいて提供

– 新バージョンは1.3.8 (2008年5月現在)

– Webコンテナー上で動作(1.3.8の場合、Servlet2.3 / JSP1.2以上)

– MVC Model 2 デザインを採用

（Controller）

Servlet

（View）

JSP

1.Request

5.Response

3 （Model）

JavaBean

4

2instantiate

Application Server Enterprise Servers/ DataSource


Strutsの機能MVC2に基づいたアプリケーションデザインを提供

– ActionServletと呼ばれるサーブレットがリクエストを受付ける。Actionクラスへの割振

りやJSPへのフォワードはRequestProcessorというクラスがおこなう。

– 実際の処理はActionクラスに記述

– ActionFormというJavaBeanを介してパラメータの受け渡しをする

JSPカスタムタグライブラリ– 開発者が対話的なフォームベースのアプリケーションを作成するのをサポート

その他、入力値チェック(Validator)、国際化サポート、画面レイアウト(tiles)などの機能を持つ

リクエスト送信

Actionクラス１

Actionクラス2

ActionServlet

フォワード

実際の処理を記述

ModelRequestProcessor

ActionForm

JSP

パラメータの受け渡し


Struts適用後

CARDB


商品一覧

index.jsp

LoadAction

SummaryAction

ThanksAction

買い物かご

summary.jsp

受付NO

thanks.jsp

CARTBL

COUNTERSummaryService

CarListService

Struts

ThanksService


注文情報格納

内容をロード

ビジネス層 + データアクセス層

ActionServlet


コード比較

- Struts適用前 -

SummaryServlet

public class SummaryServlet extends javax.servlet.http.HttpServlet implements javax.servlet.Servlet {・・・省略・・・

protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {

・・・省略・・・(ビジネスロジックを実行など)ServletContext servletContext = getServletContext();RequestDispatcher dispatcher = servletContext.getRequestDispatcher("summary.jsp");dispatcher.forward(request, response);

}

SummaryServlet

SummaryServlet内でsummary.jspへの

フォワードを実行

JSPへのフォワード

買い物かご

summary.jsp


コード比較

- Struts適用後 -

ActionServlet SummaryAction

<action-mappings><action path=“/summary” type=“sd.fw.sdstrutsweb.actions.SummaryAction” name="cartForm" scope="request">

<forward contextRelative=“false” name=“success” path="/summary.jsp"></forward></action>

・・・省略・・・</action-mappings>

struts-config.xml

public class SummaryAction extends Action {public ActionForward execute(ActionMapping mapping, ActionForm form, HttpServletRequest request,

HttpServletResponse response)throws Exception {・・・省略・・・

forward = mapping.findForward("success");return (forward);

}}

SummaryAction

設定ファイルでsummary.jspへのフォワードを定義

JSPへのフォワードについて

struts-config.xmlの定義と連携。実際

のフォワードはstrutsがやってくれる。

Actionクラスを継承

買い物かご

summary.jsp


Struts適用でどう変わったか？

画面制御を設定ファイルで一括管理できる– Struts設定ファイル(struts-cfg.xml)に記述

コンポーネント間（View-Controller）の疎結合化– View部分は独立するので、作業分担がしやすくなる

– ただし、Actionクラス-ビジネス・ロジック（Controller-Model）間は必ずしも疎結合にはなら

ない

– ビジネス層(Model)部分はStrutsでは規定されない


Spring Frameworkの適用

CARDB

商品一覧

index.jsp

LoadAction

SummaryAction

ThanksAction

買い物かご

summary.jsp

受付NO

thanks.jsp

CARTBL

COUNTERSummaryService

CarListService

Struts

ThanksService


注文情報格納

内容をロード

Spring

プレゼンテーション層とビジネス層を疎結合にするためにSpring Frameworkを用いる

ActionServlet

プレゼンテーション層ビジネス層 + データアクセス層


Spring Frameworkとは

Rod Johnson氏を中心に開発された、オープンソースのJavaフレーム

ワーク– Apacheライセンスに基づいて提供

– 新バージョンは2.5.4 , 2.0.xでは2.0.8(2008/5/9現在)

– 多岐にわたる機能を実装するフル・スタックフレームワーク

– Spring MVC– Spring JDBC– Spring DI– Spring AOP

– DIxAOPコンテナして使用されることが多い


実装クラス

DI (Dependency Injection)– 依存性(必要なコンポーネントやプロパティ)を外部から注入

– 「外部から依存性注入」をおこなうものをDIコンテナと呼ぶ

AOP (Aspect Oriented Programming)– AOPは横断的関心事をクラスの定義から分離し、必要に応じて挿入するという形をとる

– 横断的関心事とは中心となるビジネスロジック以外の処理(ロギング、トランザクション制御な

ど)で、複数のモジュールに散在するものを言う。

Springの機能 (DI x AOPコンテナ)

実装クラスBean

定義ファイル

定義の読

み込み

DIコンテナ

定義に従って

実装をセット

モジュールA

モジュールBログ処理が

散在

モジュールA

モジュールB ログ処理

Spring AOP

Class HelloClass

Interface


Strutsフレームワークとの連携SpringのDIコンテナを使用することでActionクラスとモデル層のビジネス

ロジッククラスとの疎結合化が可能Strutsとの連携用にSpring側で2つのクラスが用意されている

– ActionSupport

– DelegatingActionProxy

ActionServlet

Action

Action

マッピン

グ情報

JSPJSP

ビジネス

ロジック

ビジネス

ロジック

Controller Model

View

疎な結合に

するべき

Springで疎結合化


ActionSupportを使用した連携

ActionSupportとは– ActionSupportを継承することによりActionクラスからSpringの機能が使用可能に

なる

Spring側で用意されたDelegatingActionProxyを使って、StrutsのActionクラスごとDIコンテナによって管理する方法もある

ActionServlet

Action

Action

マッピン

グ情報

JSPJSP

ビジネス

クラス

ビジネス

クラス

Controller Model

View

Action サポートクラス

Spring

DI

Struts


SummaryServiceImpl

LoadAction

SummaryAction

Spring Framework適用後

CARDB

商品一覧

index.jsp

買い物かご

summary.jsp

受付NO

thanks.jsp

CARTBL

COUNTER

Struts


注文情報格納

内容をロード

<<Interface>>CarListService

CarListServiceImpl

ThanksServiceImpl

Spring

ActionServlet

DI

DI

DI

ThanksAction

<<Interface>>SummaryService

<<Interface>>ThanksService

※ ： SpringのDIによって依存性注入DI



public class LoadAction extends Action {public ActionForward execute(ActionMapping map,ActionForm form,HttpServletRequest

request,HttpServletResponse response){・・・省略・・・

//Car一覧を取得CarListService carListService = new CarListServiceImpl();ArrayList<CarInfo> records = carListService.getRecords();

//DBのレコードrequestスコープに格納request.setAttribute(“records”, records);

//フォワードreturn map.findForward("success");

}}

コード比較

- Spring適用前 -Spring適用前のActionクラス

LoadAction

CarListServiceImplインスタンスをAction の中で作成

CarListServiceImplに依存

StrutsのActionクラスを継承LoadAction

CarListService


コード比較

- Spring適用後 -Spring適用後

public class LoadAction extends ActionSupport {public ActionForward execute(ActionMapping map,ActionForm form,HttpServletRequest,

request,HttpServletResponse response){・・・省略・・・

//Car一覧を取得(Spring Stuts連携機能を利用)CarListService carListService = (CarListService)getWebApplicationContext().getBean("carListService“);List records = carListService.getRecords();・・・省略・・・}

}

LoadAction Struts連携用のActionSupportクラスを継承

<beans><bean id=" carListService" class="sd.fw.sdstrutsweb.service.CarListServiceImpl“> </bean>

</beans>

applicationContext.xml (Bean定義)

carListServiceの定義。実際にはCarListServiceImplのインスタンス

ActionSupportクラスで定義されているgetWebApplicationContextメ

ソッドを利用。carListServiceというIDでSpringによって注入されたイ

ンスタンスを取得

CarListServiceImplには依存しない

LoadAction内容をロード


CarListServiceImpl

DI


Spring適用でどう変わったか？

DIの使用により、依存関係が排除できる– レイヤーをまたぐ呼び出しをインターフェース経由にし、その実体をSpringでDIすることに

よってレイヤー間を疎結合にすることができる。

Strutsとの連携– Strutsのみの適用時に問題であったController-Model間の分離が可能

– 他にもJSF、Hibernate、iBatisなどとの連携がサポートされている

設定ファイルが煩雑に


SummaryServiceImpl

LoadAction

SummaryAction

Hibernateの適用

CARDB

商品一覧

index.jsp

買い物かご

summary.jsp

受付NO

thanks.jsp

CARTBL

COUNTER

Struts


注文情報格納

内容をロード


CarListServiceImpl

ThanksServiceImpl

Spring

ActionServlet

DI

DI

DI

ThanksAction



データアクセス層のフレームワークとしてHibernateを使用Springと連携してビジネス層とデータアクセス層を疎結合にする

Hibernate



Hibernateとはオープンソースで開発されているO/Rマッピングツール

– LGPLオープンソースライセンスで配布

– 新バージョン：

3.2.6 （2008年5月現在）

– JPA (Java Persistence API) に対応

O/Rマッピング– オブジェクトとリレーショナル(主にRDBレコード)の間にある差異を吸収してリレーショナルに格納され

ているデータをオブジェクトとして直感的に扱いやすくするための仕組み

以下のようにマッピングされる– クラス⇔テーブル

– フィールド⇔カラム

– インスタンス化されたオブジェクト⇔レコード

はなこすずき743

よしおたなか126

名前名字社員ID

はなこすずき743

よしおたなか126

名前名字社員ID

70002007/2/107433

2500002007/1/251262

3000002007/1/257431

支給額支給日対象者ID手当てID

70002007/2/107433

2500002007/1/251262

3000002007/1/257431

支給額支給日対象者ID手当てID

社員テーブル

手当てテーブル

名字: たなか名前: よしお

名字: すずき名前: はなこ

支給日: 2007/01/25支給額: 300000

支給日: 2007/01/25支給額: 250000

支給日: 2007/02/10支給額: 7000

Hibernate


アプリケーションとデータベースの間に位置してRDBレコードと対応するオブジェクトの管理をおこなう

– 永続化先のデータベース定義やオブジェクトとテーブルのマッピング定義は各種設定ファイルでおこ

なう(hibernate.cfg.xml

/ <Class名>.hbm.xmlなど)

– オブジェクトはtransient/persistent/detachedの状態を遷移し、そのライフサイクル管理はHibernate

がおこなう

HQLと呼ばれるクエリ言語を提供– SQLに対応するオブジェクトベースのクエリ言語

Hibernateの機能

アプリケーション

Hibernate

オブジェクトオブジェクト

検索更新

データベース

from eg.Cat as cat where cat.name='Fritz'

HQLの例

eg.Catクラスのインスタンスでname属性がFritzで

あるオブジェクトを検索


Springフレームワークとの連携Spring側でHibernateとの連携機能が用意されている

– HibernateDaoSupport– Hibernateへのデータアクセスオブジェクト(DAO)作成のためのサポートクラス。作

成の際にはこのクラスを継承して使用する。

– HibernateTemplate– Hibernateのデータアクセスコード(追加、削除など)を簡略化

設定ファイルの統一– SpringのBean定義ファイルにHibernate設定の一部を記述可能(hibernate.cfg.xmlが

不要に)

HibernateDao Support

継承

DAOクラスSpring DIコンテナ

Hibernate

データ操作

Bean定義ファイル

(Hibernate設定も記

述)

ビジネスロジック

DI

DI

永続化オブ

ジェクト

マッピング

マッピング

ファイル

HibernateTemplate のメソッドを利用

ビジネスロジックDI


CarListServiceImpl

SummaryServiceImpl

LoadAction

SummaryAction

Hibernate適用後

CARDB

商品一覧

index.jsp

買い物かご

summary.jsp

受付NO

thanks.jsp

CARTBL

COUNTER

Struts



Spring

ActionServlet

ThanksAction



Cartbl

Counter

CarDaoImpl

CounterDaoImpl

Hibernate

マッピング

マッピング

CARTBL一覧取得

クエリを実行

COUNTERテーブル

に対するクエリを実行

<<Interface>>CarDao

内容をロード

注文情報格納

ThanksServiceImpl

<<Interface>>CounterDao

※ ： SpringのDIによって依存性注入DI

ビジネス層データアクセス層

DI

DI

DI

DI

DI



InitialContext initialContext= null;Connection conn = null;ResultSet rs = null;Statement stmt = null;DataSource ds = null;String sql = "select CARNM, CARCMP, CARPRC from CARTBL";

try {initialContext = new InitialContext();ds = (DataSource)initialContext.lookup(“java:comp/env/jdbc/cardbds");conn = ds.getConnection();

stmt = conn.createStatement();rs = stmt.executeQuery(sql);

while((rs.next())) {CarInfo record = new CarInfo();

・・・・

<省略>・・・・

}

コード比較

- Hibernate適用前 -Hibernate適用前のCarListServiceImpl

CarListServiceImpl

SQLの実行

データソースのlookup

CarListServiceImpl

DB


コード比較

- Hibernate適用後 -Hibernate適用後

public class CartblDaoImpl extends HibernateDaoSupport implements CartblDao {

public List findAll() {

//HQL実行List carList = getHibernateTemplate().find("from Cartbl");

return carList;}

CarDaoImpl

前ページのSQL実行部分に相当

HibernateTemplateクラスのfindメソッドを使用してHQLを実行

HibernateDaoSupportを継承

public class CarListServiceImpl implements CarListService {private CartblDao cartblDao = null;

public void setCartblDao(CartblDao cartblDao) {this.cartblDao = cartblDao;

}・・・省略・・・List cartblrecords = cartblDao.findAll();・・・省略・・・

CarListServiceImpl

このSetterを通じてSpringはcartblDaoへ注入

CartDaoImplには依存しない

DAO経由でDBのデータ一覧を取得

データソースのlookupは必要なし

CarListServiceImpl Cartbl

CarDaoImpl<<Interface>>CarDao

DI


Hibernate適用でどう変わったか？

アプリケーション側でのDB接続部分の考慮が少なくなる– 設定ファイルに従ってHibernate側で管理

– データソースlookupなどのコーディングは不要

SQL文を書く度合いが少なくなる

– 複雑なクエリでない限り、永続オブジェクトに対するメソッド操作で代替が可能

Hibernate まかせになってしまうため、制御しにくい部分もある– 冗長なSQLに変換されてしまう

– オブジェクトのライフサイクル管理などがHibernateまかせ


2.3 まとめ


問題点は解決されたのか・・・？

アプリケーションの変更が難しい


コードの可読性が悪い

外部の変更に弱い

DBのカラム追加など

問題点問題点フレームワーク適用後フレームワーク適用後

Spring DIおよびインターフェースの使用

により実装の入れ替えが容易に

ビジネスロジックをPOJOとして実装でき

るため単体テストがしやすくなり、コード

の可読性も向上

コーディングではなく、設定ファイルの変

更によって対応できる部分が多くなる

レイヤー化により変更の際の影響範囲が

限定され、レイヤーごとにテストも可能に


フレームワーク適用についての考察

アーキテクチャーの理解– フレームワークを使用することはフレームワークが採用しているアーキテクチャーを使用する

ことになる

– フレームワークの採用しているアーキテクチャーを理解することが必要

学習コストと開発コスト– 新たにフレームワークを学習するのは労力が必要

– ある程度の機能はフレームワークが用意してくれるので覚えると設計・コーディングなどは楽

になる

アプリケーションがそのアーキテクチャーに適合するかどうかを考える必要がある

アーキテクチャーへの理解が不足していると十分に使いこなせない

学習コストと開発コストはトレードオフの関係にある

設定ファイルへの記述のみでコーディング量が減る部分がある


3．フレームワークの歴史および今後

フレームワーク登場からの歴史および今後の展開についてお話

します。


J2EEとフレームワークのこれまでの歴史

メインストリームの逆襲～ EJB3.0の進化

J2EEの登場

Strutsの登場

軽量コンテナ（DI/AOP）

Java EE 5

エンタープライズJavaとしてJ2EEの登場

オープン・ソース・フレームワーク黎明期

J2EE神話の崩壊オープン・ソース・フレームワーク全盛期

現在


J2EEとフレームワークでみるWebアプリケーション開発の変遷

エンタープライズJavaとしてJ2EEの登場– J2EEそのものがエンタープライズ・システムの基盤を支えるフレームワークとして登場した

– アプリケーションをコンポーネント化して再利用するための枠組みを提供

– EJBによるポータビリティ、スケーラビリティ、の提供

オープン・ソース・フレームワーク黎明期– J2EEを補完する基盤として生まれたフレームワーク

– Struts：

MVCモデルにおけるフロントエンド層の明確な分離

J2EE神話の崩壊～オープン・ソース・フレームワークの全盛期– 複雑なJ2EE（特にEJB）への批判精神により生まれたフレームワーク

– Hibernate：アンチCMP、O/Rマッピングの代替

– Spring Framework：よりLight-weightコンテナを求めて

– Rod Johnson 「EJB is too complex」（J2EE Development without EJB,2004）

逆襲のメインストリーム～ EJB3.0の進化– オープンソースの設計思想と技術トレンドをメインストリームとして取り入れ進化

– アノテーション・ベース

– POJO (Plain Old Java Object), POJI (Plain Old Java Interface)– DI (Dependency Injection)– JPA（Java Persistence API）～ O/R マッピング機能の改善



ビジネス層


これまでのJ2EEの進化とオープンソース・フレームワークの関係

Servlet2.4

JDBC 3.0

EJB3.0

JSF1.2

JPA1.0

J2EE 1.4オープン・ソース

フレームワーク Java EE 5

JSP2.0

EJB2.1（Session Bean）

EJB2.1（Entity Bean）

Servlet2.5JSP2.1JSTL1.1

JDBC 4.0


Java EE はどう進化する？～Java EE 5 へ残された課題

1. JSFの開発生産性– JSFは、GUIツールによる画面デザイン、コンポーネント化によるUI部品の再利用など、Strutsに変わる

ものとして生まれたが、専用IDE（もしくはEclipseプラグイン）が必要であり、デファクトになったStrutsの

代替として使用するには依然として敷居が高い

– StrutsはServlet/JSPを補完するフレームワークとしては依然としてデファクト

2. レイヤー間のデータ連携– プレゼンテーション層、ビジネス層、データアクセス層の間でのデータのやりとりがシームレスな連携が

実現できていない

– これまでDTO（Data Transfer Object）パターンによる仲介/詰め替え処理（コンポーネント間のワイヤリ

ング）が必要であり、それぞれのコンポーネントを完全に疎結合なPOJOとして開発するには依然として

ハードルがある

– JPAをDTOとして使いまわすことも可能だが、プレゼンテーション層とデータアクセス層のオブジェクト存

続期間の違い（HTTP依存⇔トランザクション依存）があり、考慮すべき点が多いのが現実

3. JPA1.0の成熟度– JPA1.0の段階ではオープン・ソース・フレームワーク(Hibernateなど)に機能面で追いつききれていない

– クエリ言語(JPQL)の柔軟性など


Java EE はどう進化する？～オープンソース・フレームワークでみる

1. Facelets ：

JSFの開発生産性をより向上– HTML（XHTML）ベースのテンプレート・エンジンをJSFへ提供

– 専用IDEなしに、より簡単に、WYSIWYG（What You See Is What You Get：ウィジウィグ）な編集を

実現

– Faceletsの影響を受けた仕様として、

JSF2.0が策定中であり、Java EE 6へ取り込まれる予定

2. JBoss Seam ：

レイヤー間（JSFとEJB3.0の間）のデータ連携をシームレスに– DTOパターンによる仲介/詰め替え処理をコード記述することなく、JSF Managed Bean ⇔ エンティ

ティBean という連携が可能

– コンポーネント間のワイヤリングを意識することなく、コンポーネントの開発が可能

– JBoss Seam は、JSR299:Web Beans として、Java EE 6 に取り込まれる予定

3. EclipseLink ：

JPA2.0の参照実装に– 現リリースのEclipseLink1.0はJPA1.0実装だが、今後のリリースでJSR317:JPA2.0（Java EE 6 に取

り込まれる予定）の参照実装として開発されていく予定

– 現時点では仕様策定中で詳細未定だが、EclipseLinkを通してJPA2.0の実装を追うことができる



ビジネス層


Java EE 6 の進化

EJB3.1

JSF2.0

JPA2.0

オープン・ソース

フレームワーク Java EE 6


EJB3.0

JSF1.2

JPA1.0

Java EE 5


JDBC 4.0

JSR299：

Web Beans


まとめ

フレームワークとは基盤として再利用される汎用的なパターンや枠組み– 採用することによって実績のあるアーキテクチャーを考慮したアプリケーション構築が可能に

– アプリケーションの枠組みを提供してくれるため、設計、コーディングなどが容易に

フレームワークを用いたアプリケーション構築– Struts / Spring / Hibernateを用いたアプリケーション構築

– フレームワークを組み合わせることによって各レイヤーが分離され、疎結合されることによっ

て保守性がすぐれたアプリケーション構築が可能

フレームワークの今後– Java EEの仕様とオープン・ソース・フレームワークは影響しあいながら発展している

– Java EE 6にもJBoss SeamやEclipseLinkなどで実装ずみの機能がとりこまれる予定


4．（参考）WASと連携させる上での Hints & Tips


Spring/HibernateをWASと連携させるケースでの Hints & Tips

当資料では、以下の重要なポイントにしぼって解説

Spring×WAS 連携の Hints & Tips– Spring Bean から

WAS データソースを使用する方法

– Spring と

WAS トランザクション管理との連携

– Spring と

WAS スケジューリング機能の連携

– 非管理スレッドについての注意点

– Spring×WAS連携におけるクラスローダー設定に関しての考慮点

Hibernate×WAS 連携の Hints & Tips– Hibernate から


– Hibernate と

WAS トランザクションを連携させる方法

– Hibernate を使用したデータソースにおいて、複数の分離レベルをサポートするには


Spring Bean から


WAS上で稼動させる場合には、Spring フレームワークによるリソース管理ではなく、WAS が提供するリソース管理を使用することを推奨

Naming Service

DataSource

JNDI名: jdbc/Sample“Sample”

データベース

<bean id="WASDataSource" class="org.springframework.jndi.JndiObjectFactoryBean">

<property name="jndiName" value="java:comp/env/jdbc/springDS"/> <property name="lookupOnStartup" value="false"/> <property name="cache" value="true"/> <property name="proxyInterface" value="javax.sql.DataSource"/>

</bean>

<bean id="WASDataSource" class="org.springframework.jndi.JndiObjectFactoryBean">

<property name="jndiName" value="java:comp/env/jdbc/springDS"/><property name="lookupOnStartup" value="false"/><property name="cache" value="true"/><property name="proxyInterface" value="javax.sql.DataSource"/>

</bean>

<resource-ref> <res-ref-name>jdbc/springDS</res-ref-name> <res-type>javax.sql.DataSource</res-type> <res-auth>Container</res-auth> <res-sharing-scope>Shareable</res-sharing-scope>

</resource-ref>

<resource-ref><res-ref-name>jdbc/springDS</res-ref-name><res-type>javax.sql.DataSource</res-type><res-auth>Container</res-auth><res-sharing-scope>Shareable</res-sharing-scope>

</resource-ref>

Spring bean 定義ファイル

デプロイメント記述子

デプロイ時にDD上のリソース参照と

WAS上のデータソースをマップ

61 Presentation Title | Presentation Subtitle 2008 IBM Japan Systems Engineering Co., Ltd.

Spring と

WAS トランザクション管理との連携Spring 2.1 RC1 以降かつ WAS V6.0.2.19 / WAS V6.1.0.9 以降の場合：

– Springが提供する”WebSphereUOWTransactionManager”をトランザクションマネージャーとして使用する（これは内部

的にはWASの提供するUOWManagerインターフェースを使用している）

– これによりSpringが提供する宣言的トランザクション（６つのトランザクション属性すべて）をWASランタイムからサポートでき

るようになり、Springによるトランザクションの中断および再開が可能となる

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

... </bean><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>

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

...</bean><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>

Spring bean定義ファイル

WebSphereUOWTransactionManagerを使

用することにより、Springが提供する以下の６

つのトランザクション属性すべてをサポート• PROPAGATION_REQUIRED • PROPAGATION_SUPPORTS • PROPAGATION_MANDATORY • PROPAGATION_REQUIRES_NEW • PROPAGATION_NOT_SUPPORTED • PROPAGATION_NEVER

Spring 2.1 RC1 より前、または、WAS V6.0.2.19 および WAS V6.1.0.9 より前の場合：– Springによるトランザクションの中断および再開はサポートできない

– Springが提供する”JtaTransactionManager”というパッケージを使い、WASからサポートできない「Springによるトランザ

クションの中断および再開」を使わないように構成する必要がある（通常のUserTransactionとして構成する）

– Springは”WebSphereTransactionManagerFactoryBean” というWAS用パッケージも提供しているが、こちらはサポー

トされないWASの内部インターフェースを利用しているため使ってはいけない

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

<property name="autodetectTransactionManager“ value="false" /></bean>

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

<property name="autodetectTransactionManager“ value="false" /></bean>


JtaTransactionManagerを使用することも可能。た

だし、この場合、autodetectTransactionManager を

false とすることで、Springのトランザクション属性

を以下の４つに限定する必要がある。• PROPAGATION_REQUIRED • PROPAGATION_SUPPORTS • PROPAGATION_MANDATORY • PROPAGATION_NEVER


（補足）トランザクション属性について属性内容

Required 呼び出し元でトランザクションを開始していいない場合、呼び出し先で新規トランザクションを開始する呼び出し元でトランザクションを開始している場合、その既存トランザクションの中で呼び出し先のメソッドが実行される

Mandatory 呼び出し元でトランザクションを開始していいない場合、例外が発生する呼び出し元でトランザクションを開始している場合、その既存トランザクションの中で呼び出し先のメソッドが実行される

RequiresNew 呼び出し元でトランザクションを開始していいない場合、呼び出し先で新規トランザクションを開始する呼び出し元でトランザクションを開始している場合、その既存トランザクションを一時停止して、呼び出し先で新規トランザクションを開始する

NotSupported 呼び出し元でトランザクションを開始していいない場合、呼び出し先ではトランザクションを使用しない呼び出し元でトランザクションを開始している場合、その既存トランザクションを一時停止しますが、呼び出し先ではトランザクションを開始しません

Supports 呼び出し元がトランザクションを開始していない場合、呼び出し先ではトランザクションを使用しない呼び出し元がトランザクションを開始している場合、その既存トランザクションの中で呼び出し先のメソッドが実行される

Never 呼び出し元がトランザクションを開始していない場合、呼び出し先ではトランザクションを使用しない呼び出し元がトランザクションを開始している場合、例外が発生する

RequiredRequired

トランザクションを

開始

呼び出し先

メソッドXYZ（）｛

｝

呼び出し元

メソッドABC（）

トランザクションに参加

呼び出し先


｝

呼び出し元


◆ 呼び出し元で

トランザクションが開始されている


トランザクションが開始されていない

MandatoryMandatory

例外が投げられる

呼び出し先


｝

呼び出し元


トランザクションに参加

呼び出し先


｝

呼び出し元






RequiredNewRequiredNew


開始

呼び出し先


｝

呼び出し元


新規トランザクションを

開始

呼び出し先


｝

呼び出し元






NotSupportedNotSupported


開始しない

呼び出し先


｝

呼び出し元


トランザクションに参加しない

呼び出し先


｝

呼び出し元






例外

呼び出し元がロールバックしても

呼び出し先はロールバックしない

トランザクションの中断と再開が入る


（補足）JTAで提供されているトランザクション機能

1. UserTransactionインターフェース– ユーザー・アプリケーションが直接トランザクションを制御する際に利用

– トランザクションの開始、Commit/Rollbackなどを行うことができる

2. TransactionManagerインターフェース– EJBコンテナーなどがトランザクションの制御を行うために利用するAPI– 直接アプリケーション開発者が利用することを意図してデザインされていない

– TransactionManagerインターフェースが提供する機能の中には、トランザクションのsuspend/resumeの機能など

UserTransactionインターフェースでは提供されていないものがいくつかある

– これにより現在実行中のトランザクションを一時停止して別のトランザクションを開始することが可能、つまりネストした

（入れ子になった）トランザクションを実現できる（EJBのトランザクション属性へRequiresNewを指定したケースに相当）

3. XAResourceインターフェース– トランザクションマネージャーがデータベースやメッセージングシステムなどのリソースマネージャーを操作するために利用

① ② ③


（補足）UOWManagerインターフェースについて（１）WASのV6.0.2.19およびV6.1.0.9以降から提供されているインターフェースアプリケーションからWASのTransactionManagerの安全な制御を可能にする

– TransactionManagerインターフェースは、EJBコンテナでのみ使用がサポートされており、アプリケーションから利用することはサポート対象外だった

通常のUserTransactionインターフェースでは提供されていないトランザクション管理機能が使用可能となる– トランザクションのsuspend/resume機能など、NotSupportedやRequiredNewというトランザクション属性が指定できる

Spring 2.1 RC1から提供された“WebSphereUOWTransactionManager”は内部的に”UOWManager”を使用して実装しており、SpringBeanのトランザクション制御をWASランタイムへ委任することを可能とする

Context ic = new InitialContext(); UOWManager uowmgr

= (UOWManager) ic.lookup("java:comp/websphere/UOWManager"); ... try {

uowmgr.runUnderUOW(UOW_TYPE_GLOBAL_TRANSACTION,false,

new UOWAction() {public void run() throws Exception {

<< ここにトランザクション処理を記述する >>}

});} catch (UOWActionException e) {

// 処理でチェック例外が発生

}

Context ic = new InitialContext();UOWManager uowmgr

= (UOWManager) ic.lookup("java:comp/websphere/UOWManager");...try {

uowmgr.runUnderUOW(UOW_TYPE_GLOBAL_TRANSACTION,false,

new UOWAction() {public void run() throws Exception {

<< ここにトランザクション処理を記述する >>}

});} catch (UOWActionException e) {

// 処理でチェック例外が発生

}

UOWManagerを使用したコーディング例 UOWManagerをJNDIでlookupして取得

UOWManagerインターフェースのrunUnderUOW()メソッドによりトランザクション・コンテキストを設定

（１）トランザクションのタイプを指定- UOW_TYPE_GLOBAL_TRANSACTION ：

グローバル･トランザクション- UOW_TYPE_LOCAL_TRANSACTION ：ローカル･トランザクション- UOW_TYPE_ACTIVITYSESSION ：

ActivitySession （WAS独自のトランザクション・タイプ）

（２）同一種類のトランザクション･タイプが実行されていた場合にどうするか- true ：既存トランザクションを引き継ぐ- false ：

新規トランザクションを開始するなお、違う種類のトランザクション・タイプが実行されている場合には、一時停止して、新規トランザクションを開始します

（３）実行するトランザクション処理をUOWActionメソッド内に記述

UserTx1 UOWManagerApplication UOWActionTransactionManager

begin()トランザクション１

commit()

runUnderUOW()

UserTx2

run ()begin()

commit() トランザクション２


（補足）UOWManagerインターフェースについて（２）UOWManagerインターフェースは、UOWSynchronizationRegistry インターフェースをExtendsしており、JTA1.1で提供されるTransactionSynchronizationRegisitryインターフェースと同等の機能を提供

– JTA1.1はJava EE 5の仕様の一部

– 現在実行中のトランザクション・コンテキストにリソースをマップする機能、フレームワークなどがトランザクションの同期をおこなうための機能などを提供

– トランザクションマネージャーが管理するトランザクションと、直接管理できないリソース（XAでないリソース）の同期をとることが可能となる

Context ic = new InitialContext(); UOWManager uowmgr = (UOWManager) ic.lookup("java:comp/websphere/UOWManager"); //UOWManager uowsr = (UOWSynchronizationRegistry) ic.lookup("java:comp/websphere/UOWSynchronizationRegistry"); ... uowmgr.registerInterposedSynchronization(

new Synchronization() {public void beforeCompletion() {

// 2-Phase Commitの前に行う処理

}public void afterCompletion(int status)

// 2-Phase Commitの後に行う処理

}}

);

Context ic = new InitialContext();UOWManager uowmgr = (UOWManager) ic.lookup("java:comp/websphere/UOWManager");//UOWManager uowsr = (UOWSynchronizationRegistry) ic.lookup("java:comp/websphere/UOWSynchronizationRegistry");...uowmgr.registerInterposedSynchronization(

new Synchronization() {public void beforeCompletion() {

// 2-Phase Commitの前に行う処理

}public void afterCompletion(int status)

// 2-Phase Commitの後に行う処理

}}

);

UOWManagerを使用したトランザクション同期処理の例 UOWManagerをJNDIでlookupして取得UOWSynchronizationRegistryを取得してもよい

registerInterposedSynchronization()メソッドの引数へSynchronizationを実装したインスタンスを渡す。beforeCompletion()メソッドにxa_prepareに相当する処理を，afterCompletion()メソッドに引数に応じ

てCommit/Rollback （xa_commit）に相当する処理を記述することにより、トランザクション中で処理さ

れるリソースと同期して、リソースを更新することが可能となります

UserTx UOWManagerApplication Synchronization

TransactionManager

begin()new

reigisterInterposedSynchronization()

commit() beforeCompletion()

afterCompletion()

xa_prepare()

xa_commit()

複数RMへのDB更新処理

Resouce Manager (non XA)

Resouce Manager

(XA)Resouce Manager

(XA)


SpringとWASのスケジューリング機能の連携

スケジューリング機能には”WorkManagerTaskExecutor”クラスを使用すること– Springにはスケジューリング機能（非同期プログラミング）を実現するパッケージ（TaskExecutorクラス）は、

WASでサポートされるもの（SpringからWASへスレッド管理を委任できるもの）は、CommonJ WorkManagerを利用するWorkManagerTaskExecutorパッケージのみ

– それ以外のSpringスケジューリング・パッケージ（java.util.timer、quartz、backportconcurrentなどをサ

ポートするパッケージ）は、WAS（コンテナー）が管理できないスレッドを生成するため使用してはいけない

Naming Service

WorkManagerJNDI名: wm/MyWorkManger

<bean id="taskExecutor" class="org.springframework.scheduling.commonj.WorkManagerTaskExecutor"> <property name="workManagerName" value=“java:comp/env/wm/MyWorkManager"/> <property name="resourceRef" value=“true"/>

</bean>

<bean id="taskExecutor" class="org.springframework.scheduling.commonj.WorkManagerTaskExecutor"><property name="workManagerName" value=“java:comp/env/wm/MyWorkManager"/><property name="resourceRef" value=“true"/>

</bean>

<resource-ref> <res-ref-name>wm/MyWorkManager</res-ref-name> <res-type>commonj.work.WorkManager</res-type> <res-auth>Container</res-auth> <res-sharing-scope>Shareable</res-sharing-scope>

</resource-ref>

<resource-ref><res-ref-name>wm/MyWorkManager</res-ref-name><res-type>commonj.work.WorkManager</res-type><res-auth>Container</res-auth><res-sharing-scope>Shareable</res-sharing-scope>

</resource-ref>




WAS上のWorkManagerリソースをマップ


（参考）非管理スレッドについての注意点

WASから管理されないスレッド（非管理スレッド）を使用してはいけない理由

– 非管理スレッドはJava EE コンテキスト情報にアクセスできない

– WASが提供するセキュリティ制御、トランザクション管理、高可用性といったメリットを享受でき

なくなる

– WAS管理外で（コンテナーによるスレッドなどのリソース制御の外で）、リソースが勝手に使われる

ことになる

– パフォーマンス管理に影響が出る要因となる

– WASのグレースフル･シャットダウン、リソース障害からの回復を遅らせる要因ともなる


クラスローダー設定に関しての考慮点WASのクラスロード設定を適切なものに変更する必要がある– WASは内部的にオープンソース・フレームワーク（Jakarta Commons Loggingなど）をライブラリとして利用

しているが、Springなどのフレームワークが依存するライブラリとバージョンが異なる

– WASデフォルト設定のままでは、WAS内部ライブラリが先に参照されるため、クラスローダー設定を適切に

する必要がある

– クラスローダー設定の問題がある場合には、ログに「クラスのバージョン不一致」（ClassCastException、

java.lang.VerifyErrorsなど）が出力される

クラスローダーの問題を回避するための設定– 以下の手順にて設定変更を実施

1. 依存するライブラリをアプリケーションの一部として、

EAR 上位とwarモジュールのWEB-INF/lib配下に配置し、

2. アプリケーションのクラスローダー順序の設定を

「PARENT_LAST（親が後）」に変更する

（アプリケーション･サーバーのレベルで変更してもよい）

– なお、WAS6.1以降であれば、アプリケーション･サーバーの設定において、

WAS内部クラスへアクセスさせない設定（可視制限モードを有効）とする

ことも有効である

可視制限モード設定

サーバー・レベルのクラス･ローダー設定

アプリケーション・レベルのクラス･ローダー設定


（補足）WASのクラスローダー設定について

<WAR_ROOT>¥WEB-INF¥lib以下

に配置されるライブラリ

<EAR_ROOT>以下配置ライブラリアプリケーション関連付け共用ライブラリ

アプリケーション・サーバー関連付け共用ライブラリ

アプリケーション・クラスローダー

複数 (デフォルト) 単一

WAR・

クラス

ロー

ダー

モジュール(default)

アプリケー

ション

EAR 1アプリケーション・クラスローダー

E1.jar, Util1.jar


E2.jar, Util2.jar

すべてのEARアプリケーション・クラスローダー

E1.jar, Util1.jar, E2.jar, Util2.jar

WAR 1A クラスローダーW1A.war

WAR 1Bクラスローダー

W1B.war

WAR 2Aクラスローダー

W2A.warWAR 1A

クラスローダーW1A.war

WAR 1Bクラスローダー

W1B.war

WAR 2Aクラスローダー

W2A.war


E1.jar, Util1.jar

W1A.war,W1B.war


E2.jar, Util2.jar

W2A.war

すべてのEARアプリケーション・クラスローダー

E1.jar, Util1.jar, E2.jar, Util2.jar

W1A.war, W1B.war, W2A.war

クラス･ローダーの階層構造クラス･ローダー設定による違い


WAS データソースを

Hibernate から利用する設定Hibernate 構成ファイルにて ” hibernate.connection.datasource”プロパティを設定することで、WAS データソースを利用することが可能となる

– これにより

WAS ランタイムが提供する接続プール、トランザクション管理、分離レベル設定を利用できるというメリットがある

なお、Spring と Hibernate を同時に使用して連携させる場合には、Spring Bean 定義ファイルにてWAS データソース設定を実施することにより、Hibernate 構成ファイルでの設定は不要とすることも

可能

Naming Service

DataSource

JNDI名: jdbc/Sample “Sample”Database

<session-factory> …

<property name=“hibernate.connection.datasource” > java:comp/env/jdbc/hibernateds

</property> …

<session-factory>


<property name=“hibernate.connection.datasource” >java:comp/env/jdbc/hibernateds

</property> …

<session-factory>

<resource-ref> <res-ref-name>jdbc/hibernateds</res-ref-name> <res-type>javax.sql.DataSource</res-type> <res-auth>Container</res-auth> <res-sharing-scope>Shareable</res-sharing-scope>

</resource-ref>

<resource-ref><res-ref-name>jdbc/hibernateds</res-ref-name><res-type>javax.sql.DataSource</res-type><res-auth>Container</res-auth><res-sharing-scope>Shareable</res-sharing-scope>

</resource-ref>

Hibernate 構成ファイル



WAS上のデータソースをマップ


<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 >

<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 >

Hibernate と

WAS トランザクション管理との連携Hibernate 構成ファイルへ以下の２つのプロパティを設定することで、HibernateとWASのトランザクションを連

携することが可能となる– hibernate.transaction.factory_class ：

トランザクション制御を定義

– hibernate.transaction.manager_lookup_class ：

トランザクション同期の登録メカニズムを定義

トランザクション制御は「コンテナー管理トランザクション（CMT）」と「Bean管理トランザクション（UserTransaction）」の両方が使用できる

<property name="hibernate.transaction.factory_class"> org.hibernate.transaction.CMTTransactionFactory

</property> <property name="hibernate.transaction.manager_lookup_class">

org.hibernate.transaction.WebSphereExtendedJTATransactionLookup</property>

<property name="hibernate.transaction.factory_class">org.hibernate.transaction.CMTTransactionFactory

</property><property name="hibernate.transaction.manager_lookup_class">

org.hibernate.transaction.WebSphereExtendedJTATransactionLookup</property>

Hibernate構成ファイル（コンテナー管理トランザクションの場合）

hibernate.transaction.factory_classプロパティによりトランザク

ション制御を定義する。• コンテナー管理トランザクションの場合には

CMTTransactionFactory• Bean管理トランザクションの場合には

JTATransactionFactoryを設定する。

ただし、上記のトランザクション構成は、WAS V4 および V5 では使用できない点に注意！– ExtendedJTATransactionLookupプロパティーがJTA1.1仕様のExtendedJTATransactionインターフェースに依存しており、このインターフェースが

サポートされるのは WAS V6.x 以降（WBISF であれば V5.1 以降）であるため

– なお、Hibernateが他にもトランザクション構成用プロパティを提供していますが、WAS内部インターフェースを使用するものもあり、上記以外め推奨され

ません

Bean管理トランザクションの場合にのみ、jta.UserTransaction プロパティにて、WASランタイムより

取得するトランザクションのJNDI名を指定する。

Hibernate構成ファイル（Bean管理トランザクションの場合）hibernate.transaction.manager_lookup_classプロパ

ティによりトランザクション同期の登録メカニズムを定義す

る。CMT、UserTransactionの両方とも同じプロパティWebSphereExtendedJTATransactionLookupを設

定する。これによりWASランタイムと連携することが可能

となる。


（補足）ExtendedJTATransaction インターフェース

JTA1.1仕様に定義されている“拡張JTA”と呼ばれるインターフェースWAS V6.x 以降（WBISF であれば V5.1）からサポートされるこのインターフェースを使用することで、グローバル・トランザクションID、ローカル・トランザクションID へのアクセスを提供する

– これによりUserTransactionを使用するアプリ側で、TM(WAS)から割り振られたグローバル・トラン

ザクションID/ ローカル・トランザクションIDを確認できる

参考資料– InfoCenter - 「拡張JTAサポート」

http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.base.doc/info/ae s/ae/cjta_extjta.html

– InfoCenter - 「ExtendedJTATransaction」

http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.javadoc.doc/publi c_html/api/com/ibm/websphere/jtaextensions/ExtendedJTATransaction.html


分離レベルを複数設定するには？

～HibernateでWASデータソース（共有可能接続）を使用した際の考慮点WASデータソースを共有可能接続と設定する場合、複数の分離レベルを設定できず、SharingViolationが発生

– Hibernate構成ファイルにてhibernate.connection.isolationプロパティを設定していても、分離レベルを変更することはできない

それでは複数の分離レベルをサポートしたい場合には？– 共用接続（Shareable）をやめて、非共用接続（Unshareable）に変更する

– 「Hibernateセッション・ファクトリー」と「データソースのリソース参照」を複数定義し、それぞれを個別にマップする

Naming Service

DataSource

JNDI名: jdbc/Sample

“Sample”Database


<property name=“hibernate.connection.datasource” > java:comp/env/jdbc/hibernateDS01

</property> <property name=“hibernate.connection.isolation” > 1 </property>

… <session-factory> …


<property name=“hibernate.connection.datasource” > java:comp/env/jdbc/hibernateDS02

</property> <property name=“hibernate.connection.isolation” > 2 </property>

… <session-factory>


<property name=“hibernate.connection.datasource” >java:comp/env/jdbc/hibernateDS01

</property><property name=“hibernate.connection.isolation” > 1 </property>

…<session-factory> …


<property name=“hibernate.connection.datasource” >java:comp/env/jdbc/hibernateDS02

</property><property name=“hibernate.connection.isolation” > 2 </property>

…<session-factory>

<resource-ref> <res-ref-name>jdbc/hibernateDS01</res-ref-name> <res-type>javax.sql.DataSource</res-type> <res-auth>Container</res-auth> <res-sharing-scope>Unshareable</res-sharing-scope>

</resource-ref> … <resource-ref>

<res-ref-name>jdbc/hibernateDS02</res-ref-name> <res-type>javax.sql.DataSource</res-type> <res-auth>Container</res-auth> <res-sharing-scope>Unshareable</res-sharing-scope>

</resource-ref>

<resource-ref><res-ref-name>jdbc/hibernateDS01</res-ref-name><res-type>javax.sql.DataSource</res-type><res-auth>Container</res-auth><res-sharing-scope>Unshareable</res-sharing-scope>

</resource-ref>…<resource-ref>

<res-ref-name>jdbc/hibernateDS02</res-ref-name><res-type>javax.sql.DataSource</res-type><res-auth>Container</res-auth><res-sharing-scope>Unshareable</res-sharing-scope>

</resource-ref>

Hibernate構成ファイルデプロイメント記述子

デプロイ時にリソース参照とWASデータソースをマップ

Hibernateセッション･ファクトリーとリソース参照を複数定義することで、複数の分離レベルをサポート

ｈibernate.connection.isolationプロパティで「分離レベル」を設定1: ReadUncommitted （非コミット読み取り）2: ReadCommitted （カーソル固定に相当）4: RepeatableRead （読み取り固定に相当）8: Serializable （反復可能読み取りに相当）


（補足）分離レベルについてJDBCでは、トランザクションの分離レベルが4種類定義この分離レベルはDB2の分離レベルとは異なるので注意が必要

– JDBCのデフォルトの分離レベルはRR– DB2のデフォルトの分離レベルはCS

アプリケーションからは以下を意識して設定

「一度参照した照会結果に対して、どの程度変更を許容するか」

「どの程度変更を許容するか」とは？ISO分離レベルどの程度の変更を許容するか

Read Uncommited 一度参照したレコードが、無かったことになってもよい

Read Commited コミット済みのレコードだけを参照したい→ 一度参照したレコードが変更されてもよい

Repeatable Read 参照したレコードは、更新されたくない→ 読み直したときに、同じレコードが欲しい

Serializable 読み直したときに、追加のレコードが増えるのもイヤだ

JDBC ISO分離レベル DB2TRANSACTION_READ_UNCOMMITED（

カスタム・プロパティ

int値 1 ）RU Read Uncommited

非コミット読み取りUR Uncommited Read

TRANSACTION_READ_COMMITED（


int値 2 ）RC Read Commited

カーソル固定CS Cursor Stability

TRANSACTION_REPEATABLE_READ（


int値 4 ）RR Repeatable Read

読み取り固定RS Read Stability

TRANSACTION_SERIALIZABLE（


int値 8 ）S Serializable

反復可能読み取りRR Repeatable Read


参考資料

WebSphere Application Server 新動向ワークショップ（2007年4月版）http://www-06.ibm.com/jp/software/websphere/developer/was/wv61/workshop/

– 「OpenSource（Spring Framework）」および「OpenSource（O/R Mapping）」のセッションを参照

Using Spring and Hibernate with WebSphere Application Serverhttp://www.ibm.com/developerworks/websphere/techjournal/0609_alcott/0609_alcott.html

Seasar2: 第 2 回 UOWManager によるトランザクションの制御https://www.ibm.com/developerworks/jp/java/library/j_j-seasar02/

http://www-06.ibm.com/jp/software/websphere/developer/was/wv61/workshop/

http://www.ibm.com/developerworks/websphere/techjournal/0609_alcott/0609_alcott.html

https://www.ibm.com/developerworks/jp/java/library/j_j-seasar02/

ise conf. l-2 was webフレームワーク連携手法 -...

Documents