Upload Login /
...

フレームワーク 1 ISE. Web インフラストラクチャー

by user

on
Category: Documents
>> Downloads: 149
1091

views

Report

Comments

Description

Transcript

フレームワーク 1 ISE. Web インフラストラクチャー
02. フレームワーク設計
フレームワーク
ISE. Webインフラストラクチャー
Webインフラストラクチャー
清水 宣行
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
1
02. フレームワーク
Disclaimer
‰ この資料は日本アイ・ビー・エム株式会社ならびに
日本アイ・ビー・エム システムズ・エンジニアリング株式会社の正式
なレビューを受けておりません。
‰ 当資料は、資料内で説明されている製品の仕様を保証するもので
はありません。
‰ 資料の内容には正確を期するよう注意しておりますが、この資料の
内容は2009年12月現在の情報であり、製品の新しいリリース、
PTFなどによって動作、仕様が変わる可能性があるのでご注意下さ
い。
‰ 今後国内で提供されるリリース情報は、対応する発表レターなどで
ご確認ください。
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
2
OSSや他社製品の使用を推奨している訳ではありません。また、弊社が提供しているフレームワー
クとしてWACs (Web application components)がございますが、本セッションの主な対象としておりま
せんので、ご了承下さい。
・WACs
日本IBMが開発・保守を行っているWACs (Web application components)というJava言語によるシス
テム構築に必要な機能と支援ツールが統合されたアプリケーション基盤を提供しています。
Point.1：お客様の業務をシステム化する上で十分なシステム基盤機能を提供
Point.2：各種定型ロジックを自動生成するツールと豊富なガイド類
Point.3：研修サービス、オンサイトまたはリモート・サポート・サービスの提供
Point.4：標準技術をベースとしたコンポーネント構成と開発環境(JSF/Struts/Eclipse etc.)
Point.5：フレームワークの拡張方式を標準化(コンポーネントの再利用が可能)
(IBM社内情報)
Notes://D19DBR12/49256F64003015EA//0B23D0D2E07C782E49257561003E8CC3
2
02. フレームワーク
目次
‰ １．フレームワークとは
‰ ２．フレームワークの選定
‰ ３．Java
EE 6
‰ ４．まとめ
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
3
3
02. フレームワーク
本セッションの位置付け
クライアント層 プレゼンテーション層
ビジネス層
インテグレーション層
02.フレームワーク
02.フレームワーク
03.プレゼンテーション層
03.プレゼンテーション層
設計
設計 (Ajax/Dojo）
(Ajax/Dojo）
Resource Tier
Integration Tier
Business Tier
Presentation Tier
Client Tier
01.Webアプリケーション設計概要
01.Webアプリケーション設計概要
リソース層
04.Webサービス設計
04.Webサービス設計
05.非同期処理&キャッシング設計
05.非同期処理&キャッシング設計
06.データ・アクセス設計
06.データ・アクセス設計
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
4
4
02. フレームワーク
１．フレームワークとは
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
5
5
02. フレームワーク
フレームワークとは
‡ 汎用的な機能をまとめて提供し、アプリケーションの土台として機能するソフトウェ
アのこと。独自に必要とされる部分だけを開発すれば済むため開発効率の向上が見込
まれる。
‡ 汎用的に適用できるプログラムの設計モデルや典型的な処理パターンなどを含めてフ
レームワークと呼ぶ場合もある。
(by IT用語辞典 e-Words)
‰ フレームワークを採用したWebアプリケーションの開発
€
アーキテクチャーを考慮したアプリケーション設計が容易
„
„
€
明確なレイヤー化
J2EEデザインパターンの適用
メリット
„
z
z
„
レイヤー間の依存性を排除
開発方式を規定
コーディング量の減少
z
€
開発生産性の向上と品質の統一
保守性の向上
実装すべき骨組みを提供
デメリット
学習コスト
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
Developer
人材不足
スキル不足
Customer
高機能
短納期
仕様が
決まらない
仕様変更
が多い
6
開発現場の現状を考えて見ますと、開発メンバー側では人材不足やスキル不足等の課題がありま
す。人的リソースを広範囲に求めて人材を確保するとか、様々なツールを駆使して効率を上げるな
どの取り組みがありますが、プロジェクトには予算があり、予算が足りないため十分に実施できないと
いうケースもあるかと思います。また、ユーザー側では高機能・短納期の要望、仕様が決まらない、
仕様変更が多い等の課題があります。
そこで、Webアプリケーションをフレームワークを採用して開発することで、アーキテクチャーを考慮
したアプリケーション設計が容易になり、開発生産性の向上と品質の統一を実現でき、この課題をあ
る程度解決することができます。
プレゼンテーション層、ビジネス層、インテグレーション層にレイヤーが分離することで、アプリケー
ションを構成する機能単位で設計/実装することができます。また、 Service to Worker、Factory
Method、Singletonなどと言ったレイヤー毎に適したGoFのJ2EEデザインパターンを適用することで
効率的に設計することができます。
＜補足＞ レイヤーパターン
レイヤーで構造を考え、実現する考え方を「レイヤーパターン」と呼びます。このパターンの典型的な
例が、OSI参照モデルになります。JDBCも、JDBCドライバーとJDBCドライバーマネージャーとアプリ
ケーションにレイヤーが分かれています。
6
02. フレームワーク
MVCモデル、レイヤーとの関係
プレゼンテーション層
ビジネス層
インテグレーション層
コントローラー(C)
Servlet
モデル(M)
MVC
・リクエスト処理の受付
・ビジネス層への受け渡し
システム固有な処理
O/Rマッピング
モデル(M)
データベースアクセス専門
・DBへのアクセス処理
データベース
JavaBean
ビュー(V)
JSF
JSP
DI/AOP
・インスタンス管理、接続プール、参照の注入、トランザクション制御
EJB
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
7
MVCモデルは、1970年代に登場したオブジェクト指向プログラミング言語であるSmalltalkでGUIア
プリケーションを作成するために考案された考え方です。モデル(Model)、ビュー(View)、コントロー
ラー(Controller)の3つのオブジェクトを定義し、連携することで目的の機能を実現します。MVC
Model2は、Webアプリケーション開発において、ビューをJSP、コントローラーをServlet、モデルを
JavaBeanで実装し、レイヤーパターンを取り入れています。これにより、モデルを複数のビューやコン
トローラーで再利用することができ、.NETやJavaと言った異なるプラットフォームのアプリケーションか
らモデルを共有して使うという考え方にまで発展させることができます。このアプローチはCORBA
(Common Object Broker Architecture)であり、CORBAの概念をJava EEの世界で実現しようとしたア
プローチがEJBです。デメリットとしては、ビューとコントローラー間が蜜結合となってしまうことや、モ
デルの変更の影響をビューやコントローラーが受けてしまう可能性があることが挙げられます。この
デメリットを解決するため、ビジネス層とインテグレーション層の2層にまたがっているモデル部分を分
離し、各層毎に専用のクラスを用意して4つのオブジェクトが連携して処理が行われるようにします。
これにより、各オブジェクトの責務がよりはっきりし、実装やテストを分業して実施することができます。
•MVCフレームワーク
アプリケーションを、アプリケーション・データとそのデータへのアクセス制御を行うビジネス処理
(Model)、表示・入出力処理(View)、制御処理(Controller)の3つに分けたMVCモデルに従ったフ
レームワークで、各処理の独立性と高い保守性を確保します。これは、クライアントからのリクエスト受
付や、ビジネス・ロジックの振り分けを行うプレゼンテーション層に位置付けられます。
•O/Rマッピング・フレームワーク
Javaオブジェクトとリレーショナルデータベースのレコードをマッピングすることで、オブジェクトの
データ取得やデータの永続化にかかわるプログラミング作業を軽減するためのフレームワークです。
これは、JDBCやJMSといった外部リソース・システムとの通信を管理する層であるインテグレーション
層に位置付けられます。
•DI/AOPフレームワーク
コンポーネント間の結合度を下げ保守性・再利用性を高めるためのDIと、複数コンポーネントに含ま
れる共通処理を分離して保守性を高めるAOPを組み合わせたフレームワークです。これは通常、
J2EE/Java EEの各層をまたぐ基盤技術として利用されます。
7
02. フレームワーク
２．フレームワークの選定
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
8
フレームワークの歴史を振り返えるとともにフレームワークが提供している機能を確認し、Java EE 5
および2～3年後を見据えた今後のフレームワークの選定指針をご説明します。
8
02. フレームワーク
フレームワークの歴史
フルスタック化
キーワード
Javaバッチ
DI/AOP
MVC Model2
の確立
EoD
Web2.0
2000
2001 2002 2003
2004
2005
2006
2007
J2EE
Struts
2008
2009
Ease of Development
・シンプルでコアなクラスで作成
- POJO
・ルールを別な技術で補完
- DI/AOP、アノテーション
軽量コンテナ
Java EE 5
フレームワーク進化
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
9
「J2EE」は、J2EEそのものがエンタープライズ・システムの基盤を支えるフレームワークとして登場し
ました。アプリケーションをコンポーネント化して再利用するための枠組みが提供され、EJBによる
ポータビリティ、スケーラビリティを実現しました。
続いて、J2EEを補完するフレームワークとして「Struts」が登場しました。Strutsは、MVCモデルにお
けるプレゼンテーション層とビジネス層、インテグレーション層を分離し、コンポーネント間の疎結合
化を実現しました。
「軽量コンテナ」では、複雑なJ2EE、特にEJBへの批判精神により新しいフレームワークが登場しま
した。EJBを使用したアプリケーション開発は難易度が非常に高く、さらにEJBコンテナがないとテスト
できないとか、難解なEJBの仕様を理解しなければいけないというのが、EJB批判の理由です。それ
に対して、Spring FrameworkはよりLight-weightなコンテナを求め、HibernateはCMPのアンチテーゼ
およびO/Rマッピングの代替を実現しました。
「Java EE 5」では、オープンソースの設計思想と技術トレンドをメインストリームとして取り入れ、
EJB3.0/JPA1.0として進化しました。アプリケーションとして作成すべき機能をObjectクラスのようなシ
ンプルでコアなクラスで作成し(POJO)、HttpServeltクラスを継承する、web.xmlに決められた情報を
入力する等のルール部分をDI/AOP、アノテーションという技術によって補完するという考えが取り込
まれています。
「フレームワーク進化」では、機能拡張、バグ修正、最新技術トレンドの取り込みを行い、バージョン
アップすることで更なる進化を遂げています。
9
02. フレームワーク
フレームワークの黎明期から全盛期
2005
‰ J2EEの課題
€
€
レイヤーの役割分担があいまい
パフォーマンスがあまり良くない
2006
2007
2008
Struts
～フレームワーク黎明期
軽量コンテナ
～J2EE神話の崩壊、フレームワーク全盛期
‰ オープンソース・フレームワークの登場
€
Struts
„
„
€
Hibernate
„
„
„
€
MVC2モデルに基づいたデザインによる、コンポーネント間の疎結合化
柔軟な画面遷移、入力値チェック等の機能
データアクセスの煩雑さを排除
O/Rマッピングの代替
CMPのアンチテーゼ
プレゼンテーション層
ビジネス層
インテグレーション層
Spring
„
„
DI/AOPによる、レイヤー間の依存性を排除
EJBのアンチテーゼとしてのLight-weightなコンテナ
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
10
典型的なJ2EEアプリケーションではレイヤーの役割分担があいまいであっため、「チーム開発がし
ずらい」とか、「変更、機能拡張、テストが容易ではない」という課題がありました。また、フルスタック
であるがため、パフォーマンスがあまり良くないという課題もありました。この課題の解決すべく、特定
の機能に特化したオープンソース・フレームワークが登場しました。
Strutsは、MVC2モデルに基づいたアプリケーションデザインを提供しており、柔軟な画面遷移、入
力値チェック、国際化対応等の機能が提供されています。コンポーネント間の疎結合化が実現され、
開発効率の向上、作業分担の容易、画面デザインの変更に強い、一定の品質を保てる、国際化対
応が容易、柔軟な画面遷移が実現できる、JSP の可読性が向上する等の様々なメリットを享受できま
す。
HibernateはO/Rマッピングツールになり、リレーショナル・データベースのレコードをjavaオブジェク
トとして直感的に扱えるようにするための仕組みが提供されます。これにより、データアクセスに関す
る様々な問題や煩雑な処理から、開発者を解放できるというメリットを享受できます。
Springは、Rod Johnson氏の著書 “Expert OneonOne J2EE Design and Development” の中で使用
されたコードを元にしたオープンソースのJ2EE アプリケーションフレームワークです。Spring Coreや
Spring AOP、Spring DAO等の複数のモジュールから構成されます。SpringはDIコンテナであり、イン
タフェースを利用した設計/実装を実現し、開発効率の向上、変更に柔軟、機能拡張が容易等のメ
リットを享受できます。さらにSpringはAOPを提供しており、AOPを利用したトランザクション管理、例
外処理、ログ処理を行うことで、開発効率の向上、テスト容易性の向上、複雑な技術の隠蔽等のメ
リットを享受できます。
＜補足＞Front ControllerパターンとApplication Controllerパターン
Front Controllerパターンは、リクエストの開始となるServletを1つにし、コンテナはそのServletしか呼
び出さないことで、「HTTPリクエストを処理するポイント」を一元化する考え方です。Application
Controllerパターンは、HTTPリクエストを実際に処理するためのクラスとビューを生成するためのJSP
の処理制御を一元化する考え方です。 Strutsはこのパターンを組み合わせています。また、これに
より機能的な分離ができ、Application ControllerはServletである必要がなくPOJOで作成でき、テスト
効率を向上させることができます。
10
02. フレームワーク
あるWebアプリケーション
Action
Employee
Service
Employee
DB2Dao
RDBMS
‰ 処理内容
€
社員情報の検索
‰ 特徴
€
€
フレームワークを採用していない
インタフェース、DI/AOPを利用していない
‰ 課題
€
€
チーム開発がしずらい
変更、機能拡張、テストが容易ではない
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
11
11
02. フレームワーク
Struts適用
～コンポーネント間の疎結合化
Strutsが提供
Action
⑥リクエスト情報と設定ファイルによ
＜処理A＞
②委譲
Request
Action
りリクエスト処理に関するオブジェク
Action
トを決定
-Servlet
リクエストパラメーターの取得
Processer
Servlet
リクエスト処理毎
- 取得した値の検証
ブラウザ
の処理
- ビジネスロジックへの割り振り
リクエスト処理
リクエスト処理
の窓口 - 画面遷移
の制御
Employee
Action
⑥処理結果
Service
・・・
顧客データ
検索
/
登録
⑤入力情報などを格納するオ
＜処理B＞ ブジェクトの生成と値の設定
開発者が設定した
＜処理C＞
指示書の読み取り
⑦フォワード
参照が渡される
Action
・・・
①リクエスト
struts-config.xml
JSP
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
Form
リクエスト
パラメーター
12
アプリケーションの”Action”部分に、リクエストパラメーターの取得、取得した値の検証、ビジネスロ
ジックへの割り振り、画面遷移等を処理毎にコーディングする必要がありましたが、Strutsが提供する
機能によって実現することができます。
ActionServletがリクエスト処理の最初の窓口になり、RequestProcesserに委譲します。この
RequestProcesserがActionクラスの割り振りとJSPへのフォワードを行います。リクエストパラメータを格
納するための専用クラスはActionFormと呼ばれ、パラメーターを取り出してその内容を格納します。
実際にリクエストを処理するクラスはActionと呼ばれ、設定ファイルからどのリクエストの時はどの
Actionクラスを使うべきかが判断され、インスタンス化されてメソッドが実行されます。このように、
Struts適用により、コンポーネント間を疎結合化を実現でき、以下のメリットを享受できます。
・開発効率の向上：リクエストパラメーターの取得や再表示機能をStrutsが提供する。
・作業分担の容易：Model/View/Controllerが疎結合になるため、作業の分担が容易となる。 (ロジッ
ク(Model)、デザイン(View)、画面遷移(Controller)担当者)
・画面デザインの変更に強い：画面デザインの変更が発生した場合でも ModelやController の修正
は不要であり、ViewであるJSP の修正だけで済む。
・システム品質の向上：Strutsが動作の流れを規定するため、 開発者によって作り方が異なる事態を
防げる。
・国際化対応が容易：リソースバンドルを利用したマルチリンガルに対応している為、各国語用のリ
ソースファイルを用意するだけでクライアントの環境に応じたコンテンツを表示できる。
・柔軟な画面遷移の実現：画面遷移情報をstruts-config.xmlに設定する為、複雑になりがちな画面
遷移処理を容易に記述できる。
・JSP の可読性が向上する：タグライブラリの利用により、JSPの記述に一貫性を持たせることができ、
スクリプトレット等を埋め込む事による可読性の低下を防ぐ事が可能になる。
・ struts-config.xml
リクエストを把握するための情報、リクエストパラメーターを格納するクラス、リクエストや処理結果毎
のJSPのフォワード先が定義される。
12
02. フレームワーク
Hibernate適用
～データアクセスの煩雑さを削除
社員テーブル
支給日: 2007/01/25
支給額: 300000
名字: たなか
名前: よしお
Employee
DB2Dao
RDBMS
支給日: 2007/01/25
支給額: 250000
名字
名前
126
たなか
よしお
743
すずき
はなこ
手当てテーブル
名字: すずき
名前: はなこ
支給日: 2007/02/10
支給額: 7000
全体の設定
hibernate.cfg.xml
O/R マッピング定義
<Class名>.hbm.xml
オブジェクト指向
・クラス
・フィールド
・インスタンス化されたオブジェクト
‰
社員ID
インピーダンス
ミスマッチ
手当てID
対象者ID
支給日
支給額
1
743
2007/1/25
300000
2
126
2007/1/25
250000
3
743
2007/2/10
7000
リレーショナルデータベース
・テーブル
・カラム
・レコード
HQL (Hibernate Query language)
€
オブジェクトをベースとしたSQLライクなクエリ言語
from
fromise.com.Employee
ise.com.Employeewhere
whereemployee.Id
employee.Id==‘126’
‘126’
SQLレスな開発
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
13
SQLを発行した結果セットから必要な情報を取り出してオブジェクトに構築していくという(※)、リ
レーショナルとオブジェクト指向のデータ表現の違いをコードレベルで埋め合わせる必要がありまし
たが、Hibernateが提供する機能によって実現できます。業務そのものの実装とは異なり、かつ
RDBMSの接続情報等、面倒で繰り返しの多い作業をツールによってある程度自動化することができ
ます。 Hibernate適用により、データアクセスの煩雑さが削除され、開発効率の向上とシステム品質
の向上が見込まれます。
(※)データのUPDATEやINSERTの際に、オブジェクトからデータを取り出してSQL文を構築するなど
は、アプリケーション構築の本来の目的やアプリケーションの主要な機能の実装とは別に手間の掛
かる作業です。テーブルカラムを取り違えてしまうなどの気が付きにくいミスが生まれるからです。ま
た、データベースのスキーマを変更したらアプリケーション内のSQLを広範囲にわたって修正する必
要があります。
＜補足＞
・hibernate.cfg.xml：Hibernate全体の設定
JDBC接続情報、ログ関連、L2キャッシュ設定、トランザクション設定、スキーマDDL設定、O/Rマッピ
ング定義ファイルリスト等。
・<Class名>.hbm.xml：O/Rマッピング定義
永続化オブジェクト・クラス名、対応するテーブル名、主キー定義、プロパティーのテーブルへのマッ
ピング情報、関連のマッピング、クラス継承のマッピング、JOINするテーブル設定。
・Hibernateのクエリ
- HQL：オブジェクトをベースとしたSQLライクなクエリ言語
- Criteria：検索条件を文字列ではなくメソッド呼び出しで組み立てる
- ネイティブSQL：RDBMS特有のSQLで検索条件を指定する
・Hibernateの状態 (transientとdetachedがGarbage Collectionの対象)
- transient : Hibernateによって管理されていない。
- persistent : Hibernateによる管理対象となっているオブジェクト。 永続化対象としてデータベース
との間でデータの同期がとられる。
- detached : 管理されている（persistent）状態から管理対象外になったオブジェクト。
13
02. フレームワーク
Spring適用
～レイヤー間の依存性を削除
Employee
Dao
Employee
Service
Action
Employee
ServiceImpl
Employee
DB2Dao
RDBMS
ブラウザ
生成
Bean定義
ファイル
Injection
Spring
‡ インターフェースを区切りとしたチーム開発
‡ 複雑な技術の隠蔽とコーディング量の減少による、
開発効率 / テスト容易性の向上
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
生成
Injection
Advice
・トランザクション処理
・ログ処理
・例外処理 等
14
インターフェースを注入することで、このインターフェースを区切りとして、チームの開発効率を向
上させることができます。 Factory MethodなどのJ2EEデザインパターンの導入にて実現できますが、
Springを使用した方がより容易に実現できるかと思います。また、トランザクションやログ、例外処理を、
既存のオブジェクトに影響を与えないで追加することができ、コーディング量が減るとともに、開発効
率およびテストの容易性を向上させることが出来ます。
＜補足＞
Factory Methodとは、スーパークラス側で処理の骨組みを作り、サブクラス側で具体的な処理の肉
付けを行う考え方のこと。インスタンスの作り方をスーパークラス側で定めますが、具体的なクラス名
までは定めません。具体的な肉付けは、すべてサブクラス側で行うことにより、インスタンス生成のた
めの骨組みと、実際のインスタス生成のクラスとを分けて考えることができるようになります。
14
02. フレームワーク
メインストリームの逆襲
2006
‰ EJBの課題
€
€
€
€
2009
～メインストリームの逆襲
EE 5の登場
オープンソースの設計思想と技術トレンドをメインストリームに取り入れる
„
„
€
2008
Java EE 5
EJB is too complex
非常に作るのが難しい
単体テストが困難
O/Rマッピングが使いにくい、制約が多い、遅い
‰ Java
2007
開発テーマ ：Ease of Development
キーテクノロジー：POJO、アノテーション、DI/AOP
メインアップデート
„
„
EJB 3.0
JPA 1.0
プレゼンテーション層
ビジネス層
EJB3.0
インテグレーション層
JPA1.0
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
15
EJBを作るのが非常に難しい(※)、単体テストが困難、O/Rマッピングが使いにくい、制約が多い、
遅いという課題がありました。Springを作成されたRod Johnson氏が「EJB is too complex」(J2EE
Development without EJB、2004)と言われたのは、あまりにも有名です。
(※)本質的なビジネス・ロジックとは関係ない作成物、実装コードが多い。継承、実装のお作法、API
が複雑。EJB クライアントもコーディングのお作法が複雑。
これに対してJava EE 5では、オープンソースの設計思想と技術トレンドをメインストリームとして取り
入れ、EJB3.0/JPA1.0として進化しました。アプリケーションとして作成すべき機能をObjectクラスのよ
うなシンプルでコアなクラスで作成し(POJO)、HttpServeltクラスを継承する、web.xmlに決められた情
報を入力する等のルール部分をDI/AOP、アノテーションという技術によって補完するという考えが
取り込まれています。
＜補足＞
EJB 3.0：
開発者は EJB コンポーネントを、Java ビジネス・インターフェースを使用したPOJOとしてプログラミン
グすることができ、開発が単純化。ビジネス・ロジックを提供するコンポーネントのフレームワークで、
ミッション・クリティカルな分散システムの構築が可能になります。
- EJBコンテナが提供する機能
トランザクション管理、ビジネス・ロジックのアクセス制御、タイマーサービス、リモート呼び出し（分散
オブジェクト処理）、データの永続化
- EJBの種類
Session Bean：ビジネス・ロジックの実装、Stateless BeanとStateful Bean
Message Driven Bean：キューからメッセージを取得し、非同期にビジネスロジックを実行
Entity：データの永続的な保存、Entity ClassとEntity Object
JPA 1.0：
Java EE 環境において、単純化されたパーシスタンス・テクノロジーを提供する。POJOをO/Rマッピ
ングにより、透過的にパーシスタンス・データに変換する。EJBやJPA固有のクラス、例外の継承、実
装、throwが不要。
15
02. フレームワーク
Java EE 5
～EJBサンプル
EJB 3.0
EJB 2.1
public
publicclass
classCartBean
CartBeanimplements
implementsSessionBean
SessionBean{ {
private
privateSessionContext
SessionContextctx;
ctx;
public
publicint
intsomeShoppingMethod()
someShoppingMethod(){ {……} }
public
publicvoid
voidejbCreate()
ejbCreate(){ {} }
public
publicvoid
voidejbRemove()
ejbRemove(){ {} }
public
publicvoid
voidejbActivate()
ejbActivate(){ {} }
public
publicvoid
voidejbPassivate()
ejbPassivate(){ {} }
public
publicvoid
voidsetSessionContext
setSessionContext(SessionContext
(SessionContextctx)
ctx)
{ {} }
}}
Enterprise Bean Class
Home Interface and Remote Interface
Object obj =
Object obj =
Context.lookup(“java:comp/env/ejb/MyCartHome”);
Context.lookup(“java:comp/env/ejb/MyCartHome”);
CartHome theCartHome = (CartHome)
CartHome theCartHome = (CartHome)
PortableRemoteObject.narrow(obj、
PortableRemoteObject.narrow(obj、
CartHome.class);
CartHome.class);
ShoppingCart myCart = theCartHome.create() ;
ShoppingCart myCart = theCartHome.create() ;
myCart.someShoppingMethod();
myCart.someShoppingMethod();
Session Bean Client
@Stateful
@Stateful
public
publicclass
classCartBean
CartBeanimplements
implementsShoppingCart
ShoppingCart{ {
}}
public
publicint
intsomeShoppingMethod()
someShoppingMethod(){ {......} }
Enterprise Bean Class
・コーディング量が少ない
・アノテーションを活用
・Home Interfaceの必要なし
・Bean Classは、Business Interfaceをそのまま
実装
@EJB
@EJB
private
privateShoppingCart
ShoppingCart myCart;
myCart;
public
publicvoid
voidsomeMethod()
someMethod(){ {
myCart.someShoppingMethod();
myCart.someShoppingMethod();
}}
Session Bean Client
・実行時にインスタンスを注入
・アノテーションを活用
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
16
EJB 3.0 では、特別なお作法に惑わされること無く、ビジネス・ロジックを実装しているクラスの作成
と、その公開メソッドをそのままインターフェースとして公開するという非常に素直なコーディングに
なっています。また、EJBであることは、アノテーション(@Remoteや@Stateless)を使用して示し、EJB
固有のクラスやインターフェースの継承や実装は必要ありません。さらに、これまでのEJB 2.x の時と
は、クライアント側のコーディングも変わり、Homeオブジェクトをlookupする必要はありません。直接、
Business Interfaceを実装したインスタンスを取得し、そのメソッドが実行できます。また、Business
Interfaceを実装したインスタンスの取得方法も、コード上でlookupする方法だけでなく、アノテーショ
ンを使用したDIで取得することができます。これにより、非常にシンプルなコーディングでEJB呼び出
しを行うことができます。また、アノテーションを使用したDIを利用することにより、EJBサーバー側が
完成していなくても、簡単にモックオブジェクトを作成・登録できますので、EJBクライアント側のテスト
も容易に行うことができます。
＜参考情報＞
EJB3.0/JPA1.0の詳細につきましては、以下のワークショップ資料をご確認下さい。
・WAS V6.1 Feature Pack for EJB 3.0 ワークショップ
http://www.ibm.com/developerworks/jp/websphere/library/was/was61_ejb3fep_ws/
16
02. フレームワーク
フレームワークの発展
‰ フレームワークの課題
€
€
€
XML設定ファイル地獄
テスト効率があまり良くない
Ajaxアプリケーションへの対応
2007
SSHは
XMLの三重苦
2008
2009
フレームワーク進化
～フレームワークの発展
生産性・テスト効率
が悪い
学習コスト
がかかる
‰ フレームワークの進化
€
€
€
設定ファイルの簡潔化とアノテーション
Hot Deploy (Reloading)機能
Ajax対応フレームワーク
Seasar 2.3 (2005.11)
Spring 2.5 (2007.11)
Seasar 2.4 (2006.11)
プレゼンテーション層
ビジネス層
EJB3.0
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
Light Language
インテグレーション層
JPA1.0
17
デファクトスタンダードと言っても過言でない程、オープンソースのフレームワークが台頭しましたが、
課題が全くなかった訳ではありません。たしかに、フレームワークの採用によりコードディング量が減
りましたが、代わりにXML設定ファイルを書く量が増え、XML設定ファイル地獄が発生しました。SSH
(Struts / Spring / Hibernate)は、「XMLの三重苦」とも言われたりしています。また、POJOとDIによっ
てテストの容易性は向上しましたが、それは単体テストだけに当てはまるもので結合テストには当て
はまりませんでした。生産性はEJBより良いが低かったという現状があり、生産性の高いRuby on
Railsが注目を集めました。
この課題を踏まえて、コンポーネントの自動登録とアノテーションの組み合わせによるXML設定
ファイル地獄の解消が図られました。Seasarは2005年11月公開のバージョン2.3で、Springは2007年
11月公開のバージョン2.5で実現してます。さらに、開発生産性を向上すべく、アプリケーションサー
バを稼働させたままソースコードの修正が即座に反映されるHot Deploy (reloading)機能が、2006年
11月のSeasarの2.4で実現されました。これにより、JavaでもRubyなどのいわゆる「LL (Light
Language)」と同様にさくさくとした開発が可能になっています。また、別の観点では、よりリッチな
ユーザーインタフェースを提供するAjaxアプリケーションの台頭により、そのAjaxアプリケーションを
容易に開発できるオープンソースのフレームワークも登場しています。
17
02. フレームワーク
フレームワークの発展
～Struts編
‰ Struts1.xの課題
€
XML設定ファイル地獄
„
‰ 選択指針例
スタート
struts-config.xml、validation.xml
アプリケーションを実行するまで、わからない
€
テスト効率があまり良くない
„
„
設定ファイルとクラスの関連の再定義
ソースコード修正時の再起動
Struts1.xの
既存プロジェクト
Yes
S2Strutsの
既存プロジェクト
‰ 主な機能拡張
No
No
Yes
Struts 2.x
(Struts + WebWorks)
S2Struts
(Struts1系 + Seasar)
SAStruts
(Struts1系 + Seasar)
‡ ActionクラスのPOJO化
‡ アノテーション対応
‡ 設定ファイルの最小限化
‡ 設定ファイルが必要ない
‡ Hot Deploy機能
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
S2Struts
SAStruts
Struts2.x
‡ 互換性
Struts2とStrus1の下位互換性がない
‡ バージョン
JDK1.4環境は、S2Struts
18
Strutsを利用して開発されたアプリケーションの数は膨大であり、最も人気の高いフレームワークと
言っても過言ではありません。しかしながら、XML設定ファイル地獄やテスト効率が良くないという(一
部の)現場開発者の不満もありました。特にXML設定ファイルは、アプリケーションの実行前にコンパ
イルされて構文チェックなどが行われるわけではなく、アプリケーションの実行時に読み込まれるた
め、実行してみないと記述ミスに気付きません。多くの情報が記述されている場合には、どこが間
違っているかを発見するのが大変手間になります。
Struts2.xでは、開発生産性とソースコードの簡素化に特徴があるWebWorkと融合され、Actionクラ
スのPOJO化とアノテーション対応と設定ファイルの最小限化が実装されました。(詳細は次ページ)
ActionクラスのPOJO化によりテスト効率が良くなり、アノテーション対応、および設定ファイルの最小
限化により開発生産性が向上しています。
また、Struts1系はDIコンテナであるSeasarとの融合により、S2StrutsとSAStrutsを選択することもでき
ます。S2Strutsは、Strutsを使用した既存アプリケーションとSeasarの連携を簡単に実現し、より簡単
にWebアプリケーションを構築するための機能が提供されています。Super Agile Struts(以降
SAStruts)は、Strutsを使った開発をSuper Agileに行なうためのフレームワークです。設定ファイルを
書く必要はなく、アプリケーションサーバを稼働させたままソースコードの修正を反映させることがで
きます。
Strus2系、S2Struts、SAStrutsの選択指針として、既にStruts1系で開発している案件はS2Strutsか
SAStrutsを、新規案件はStruts2系を選択するのが良いと思います。Struts1.xとStruts2.xで下位互換
性がないことと、Struts2.xにて様々な機能拡張がされているのがその理由です。（その反面、Struts2
系では、新たな学習コストがかかります。)また、S2StrutsとSAStrutsの選択指針は、既にS2Strutsで
開発している、もしくはJDK1.4で開発している案件はS2Strutsを、それ以外はSAStrutsを選択するの
が良いと思います。同様に、SAStrutsにてHot deploy機能等、様々な機能拡張がされているのがそ
の理由です。
18
02. フレームワーク
フレームワークの発展
～Struts2系 機能拡張
‰ ActionクラスのPOJO化
public ActionForward execute
public ActionForward execute
(ActionMapping mapping、
(ActionMapping mapping、
ActionForm form、
ActionForm form、
httpServletRequest request、 xxx)
httpServletRequest request、 xxx)
Struts1
‰ アノテーション対応
<action
<actionpath="/sample/hello"
path="/sample/hello"
type=“xxx.HelloAction"
type=“xxx.HelloAction"name=“xxx">
name=“xxx">
<forward
<forwardname="hello"
name="hello"path="/hello.jsp"
path="/hello.jsp"/>/>
</action>
</action>
Struts1
テスト効率
の向上
public
publicclass
classHelloAction
HelloAction{ {
public
publicString
StringgetMessage()
getMessage(){ {
return
return"Hello!";
"Hello!";
}}
public String execute() throws Exception {
public String execute() throws Exception {
return "success";
return "success";
}
}
}
Struts2
}
@Action("/sample/hello")
@Action("/sample/hello")
public
publicString
Stringexecute()
execute(){ {
……
……
}}
開発生産性
の向上
Struts2
‰ 設定ファイルの最小限化
€
Conventionプラグイン
„
€
設定ファイル(：struts-config.xml)が不要
Struts2.1とSpring2.5連携
„
ActionクラスによるSpring Injection機能の利用が可能
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
開発生産性
の向上
@Autowired
@Autowired
public
publicvoid
voidexecute()
execute(){ {
……
……
}}
Struts2
19
・ActionクラスのPOJO化
Struts1系のActionクラスは、Strutsが提供するActionクラスを継承する必要があります。アクションメ
ソッドであるexecute() は、戻りにActionForward、パラメーターにはActionMapping、
HttpServletRequestなどのクラスやインタフェースをパラメーターにする必要がありました。それに対
して、Struts2系のActionクラスは何も継承せずにPOJOとして作成することが可能です。
・アノテーション対応
Struts1系では定義ファイルであるstruts-config.xmlとの密接な連携が必要でしたが、Struts2系では
アノテーションで遷移先を決めることが可能です。
・設定ファイルの最小限化
Conventionプラグイン (struts2-convention-plugin-2.1.6.jar)
Struts1系では定義ファイルであるstruts-config.xmlに、利用するActionクラスやFormクラス、Actionク
ラスの処理結果を元にした遷移先のJSPファイル等を記述する必要がありました。Struts2系では、規
約を守れば、簡単なWebアプリケーションであれば、struts-config.xmlを設定する必要がなくなって
います。
・Struts2.1とSpring2.5連携
Struts1系では、Springの管理するビジネスコンポーネントをActionクラスから利用するためには
ActionSupportクラスを継承したり、リクエストプロセッサであるAutowiringRequestProcessorを置き換
えたり、 StrutsとSpringの定義ファイルを紐付けるなど様々な作業が必要でした。Struts2.1では、
Actionクラスのインスタンス変数にAutowiredアノテーションを定義するだけで実装することが可能で
す。
19
02. フレームワーク
フレームワークの発展
‰ Hibernate
‡ API
‡ Metadata
‡ HQL
～Hibernate編
3.xの主な機能拡張
EJB3.0 Annotation、JPA、merge()
Lazyロード(デフォルトtrue)
ANTLRベースのHQL/SQL翻訳エンジン
‰
選択指針例
‡ 最新版を使用する
機能拡張 / 最新技術のサポート
‰ N+1
セレクト問題
Lazyロード：
関連するオブジェクトのロードを最初にアクセスされるまで遅延する
夫テーブル
夫ID
名字
名前
1
たなか
よしお
2
すずき
のぶお
妻テーブル
妻ID
夫ID
名字
名前
1
1
たなか
よしこ
2
2
すずき
のぶこ
select
select＊
＊from
from夫テーブル
夫テーブル
→1件：select
→1件：select＊
＊from
from夫テーブル
夫テーブル
→N件：select
→N件：select＊
＊from
from妻テーブル
妻テーブルwhere
where妻テーブル.夫ID=?
妻テーブル.夫ID=?
Nレコード分だけ
SQL
を発行する
Nレコード分だけ SQL を発行する++全レコードの取得に1件
全レコードの取得に1件
join fetchの設定
テーブル再定義(主キーと外部キーの関係)
‰ キャッシュ検討
€
€
L1キャッシュ：evict()、clear()、ScrollableResults
L2キャッシュ：更新頻度が低い参照専用のテーブル
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
RDBMSのスキル
初期段階で検討
20
・Hibernateの選択指針
Hibernate 2.x is no longer being actively developed. Hibernate3 still runs perfectly with JDK 1.2.
また、Annotationを使用する場合は、Hibernate3以上が必須です。(JSR-175)
Lazyロードとは、関連するオブジェクトのロードを最初にアクセスされるまで遅延させます。使用さ
れていないオブジェクトに対してデータベースへの問い合わせを行わないことになり、リソースを節約
しパフォーマンスを向上させることができます。その反面、N+1セレクト問題とも言われていますが、
実際にデータベースにアクセスするタイミングにて、関連しあう全てのオブジェクトの処理データ+1件
分のSQLをDBに発行してしまいます。これは、RDBMSに大きな負担となり、システムのパフォーマン
スを低下させる可能性があります。この問題の対応策として、join fetchの設定やテーブルの再定義
を検討して下さい。(外部キーがない1対1関連、主キーで結合する多対1関連等、Hibernateが関連
Entityの存在を判別できない場合に発生します。)join fetchは、Lazyロードせず、外部結合によるDB
問い合わせを行います。(select fetchは、外部結合を行わず、別々のSELECT文による関連しあうオ
ブジェクトを取得します。)また、DI/AOPによって、ユースケースに応じてこのfetch設定を上書きする
ようなアーキテクチャーを検討して下さい。
L1キャッシュはデフォルト有効で、Sessionがオープンされている間、永続化オブジェクト
(=persistent)のキャッシュが保持されます。L2キャッシュはオプションで、SessinFactoryが存在する間、
JavaプロセスやAppServerのCluster間で保持されます。Session間の共有可能です。L1キャッシュは、
OutOfMemoryの発生を避けるため、特に大量のデータを扱う場合には、適宜evict() / Clear()を実
行することを心掛けて下さい。evict()は引数に渡した1つのオブジェクトを削除するのに対し、clear()
はセッション・キャッシュ上のすべてのオブジェクトを削除します。このメソッドを実行すると、(1)セッ
ション・キャッシュから永続オブジェクトを除去します。その結果、セッション管理の対象外となった永
続オブジェクトの状態は、分離オブジェクトへと遷移します(2)セッション・キャッシュから削除された永
続オブジェクトに対する更新系の処理はキャンセルされます。また、大量の検索結果を扱う場合には、
ScrollableResultsを利用して下さい。L2キャッシュは更新頻度が低い参照専用のテーブルを対象と
すると宜しいかと思います。(WASの動的キャッシュ機能と同様の考え方になりますので、05.非同期
&キャッシング設計をご参照下さい。また、L2キャッシュにつきましては、06.データアクセス設計をご
参照下さい。)
＜参考情報＞
・Hibernate3 Migration Guide：
https://www.hibernate.org/Documentation/Hibernate3MigrationGuide
・JBoss Cache, EHCache, OSCache, SwarmCache
http://docs.jboss.org/hibernate/stable/core/reference/en/html_single/#performance-cache
20
02. フレームワーク
フレームワークの発展
～Spring編
‰ Spring1.xの課題
€
DI/AOPを実現するための XML設定ファイルが複雑
‰ 主な機能拡張
Spring2.0 (2006.10)
Spring2.5 (2007.11)
Spring3.0 (2009.10)
‡ 設定ファイル簡素化と強化
‡ 設定ファイル簡素化と強化
‡ 設定ファイル簡素化と強化
- XMLスキーマの利用
- AspectJの連携強化
- カスタムスキーマ
‡
‡
‡
‡
JPAサポート
MessageDriven POJO導入
Spring JDBCの強化
Portlet MVCのサポート
‡ アノテーションの強化
‡ OSGiサポート
‡ Java EE 5サポート
設定ファイルの簡素化 / 最新技術のサポート
‰ 選択指針例
‡ 互換性
‡ バージョン
- オブジェクトとXMLの
マッピングサポート
- AspectJの連携強化
‡
‡
‡
‡
‡
アノテーションの強化
REST/SpringMVCサポート
Portlet2.0サポート
Servlet2.5との後方互換
Java EE 6先取りサポート
- JSR-303、JSR-330
WASV7は、Spring
WASV7は、Spring2.5.5以降を推奨
2.5.5以降を推奨
Spring 2.0とSpring1.x、Spring 3.0とSpring2.5の互換性あり
Spring 2.5(JDK1.4 or higher)、Spring 3.0(JDK1.5 or higher)
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
21
Springは、DI/AOPという手法を導入することで、複雑化したJava EEに代わるフレームワークとして
普及しました。しかし、その一方で、DI/AOPを実現するためのXML設定ファイルの記述が複雑であ
るという課題もありました。そこでSpring 2.0以降にて、設定ファイルの簡素化と最新技術のサポート
対応が実施されました。(XMLスキーマ、AspectJ、アノテーション等)
AspectJは、@AspectJアノテーションによってAspectJのアスペクトを定義できるようになり、AspectJと
Spring AOPの間でアスペクトを容易に共有できるようになりました。また、Bean定義ファイル中で
AspectJのポイントカット記法を記述できるようにするなどの拡張も追加されています。
Springのバージョンの選択指針においては、Springの互換性とSpringが対応しているJDKのバー
ジョンにご注意下さい。
＜補足＞
後方互換とは、新たに作られるシステムに、旧世代での古い機能を満たすように考慮され仕様に含
まれること。下位互換とは、機能やグレードが下位のシステムが、上位のシステムの規格を扱えること。
＜参考情報＞
Chapter 2. What‘s new in Spring 2.0 and 2.5? (2.7. Migrating to Spring 2.5)
http://static.springsource.org/spring/docs/2.5.x/reference/new-in-2.html
Spring3.0での機能拡張 (2.5 Overview of new features)
http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/ch02s05.html
Class JdkVersion (Spring 2.5)
http://static.springsource.org/spring/docs/2.5.x/api/index.html
Class JdkVersion (Spring 3.0)
http://static.springsource.org/spring/docs/3.0.0.RC1/javadoc-api/
WASV7.0 Information Center - 「Spring Framework」
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.nd.m
ultiplatform.doc/info/ae/ae/cspr_intro.html
21
02. フレームワーク
フレームワークの発展
～トランザクション
Spring 1.x
Spring 2.0以降
<beans>
<beans>
<!–
<!–トランザクション定義情報の設定
トランザクション定義情報の設定-->
-->
<bean
<bean
id=“dataSource“
id=“dataSource“class=“org.springframework.transaction.
class=“org.springframework.transaction.
interceptor.nameMatchTsansactionAttributeSource”>
interceptor.nameMatchTsansactionAttributeSource”>
<property
name=“properties">
<property name=“properties">
<props>
<props>
<prop
<propkey=“insert*”>PROPAGATION_REQUIRED,key=“insert*”>PROPAGATION_REQUIRED,java.lang.Exception</prop>
java.lang.Exception</prop>
<prop
<propkey=“find*”>PROPAGATION_REQUIRED
key=“find*”>PROPAGATION_REQUIRED
,readOnly</prop>
,readOnly</prop>・・・
・・・
<!–
<!–トランザクション定義情報の設定
トランザクション定義情報の設定-->
-->
<bean
<bean
id=“transactionInterceptor“
class=“org.springframework.tr
id=“transactionInterceptor“ class=“org.springframework.tr
ansaction.interceptor.TransactionInterceptor”>
ansaction.interceptor.TransactionInterceptor”>・・・
・・・
<!–
<!–BeanNameAutoProxy
BeanNameAutoProxy-->
-->
<bean
<bean
id=“autoProxy“
id=“autoProxy“class=“org.springframework.aop.framewo
class=“org.springframework.aop.framewo
rk.autoproxy.BeanNameAutoProxyCreator”>
rk.autoproxy.BeanNameAutoProxyCreator”>
・・・
・・・
Bean定義ファイル
XMLスキーマを利用したBean定義
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
aopタグとtxタグを使用した例
<aop:config/>
<aop:config/>
<aop:advisor pointcut=“execution(*..TxExBean.exMethod(…))”
<aop:advisor pointcut=“execution(*..TxExBean.exMethod(…))”
advice-ref=“txAdvice”/>
advice-ref=“txAdvice”/>
</aop:config>
</aop:config>
<tx:advice id=“txAdvice”>
<tx:advice id=“txAdvice”>
<tx:attributes>
<tx:attributes>
<tx:method name=“exMethod” propagation=“REQUIRED”
<tx:method name=“exMethod” propagation=“REQUIRED”
timeout=“20”>・・・
timeout=“20”>・・・
<bean id=“exBean” class=“txexample.TxExBeanImpl”></bean>
<bean id=“exBean” class=“txexample.TxExBeanImpl”></bean>
<bean id=transactionManager” ・・・
<bean id=transactionManager” ・・・
Bean定義ファイル
@Transactionalとtxタグを使用した例
@Transactional(
@Transactional(
propagation=Propagation.REQUIRES_NEW,
propagation=Propagation.REQUIRES_NEW,
isolation=Isolation.SERIALIZABLE,readOnly=false,
isolation=Isolation.SERIALIZABLE,readOnly=false,
rollbackFor={RuntimeException.class, IOException.class})
rollbackFor={RuntimeException.class, IOException.class})
Public classTxBeanImpl implements TxBean { ・・・ ｝
Public classTxBeanImpl implements TxBean { ・・・ ｝
Bean
<tx:annotation-driven/>
<tx:annotation-driven/>
<bean id=“exBean” class=“txexample.TxExBeanImpl”></bean>
<bean id=“exBean” class=“txexample.TxExBeanImpl”></bean>
<bean id=transactionManager” ・・・
<bean id=transactionManager” ・・・
Bean定義ファイル
22
Spring 1.xの時は、上図のように非常に設定が複雑になってしまいました。それに対してSpring 2.0
以降は、XMLスキーマおよびアノテーションを使用することにより、設定量が減り、タグによりその設
定内容が見やすくなりました。
・XMLスキーマ一覧
utilスキーマ(spring-util-2.0xsd)：定数定義やプロパティーファイルの読み込み等のユーティリティー
機能の設定を簡略化
langスキーマ(spring-lang-2.0xsd)：動的言語による設定を簡略化
aopスキーマ(spring-aop-2.0xsd)： AOPの設定を簡略化
txスキーマ(spring-tx-2.0xsd)：トランザクションの設定を簡略化
jeeスキーマ(spring-jee-2.0xsd)： JNDIのlookupおよび、EJBのlookupの設定を簡略化
＜参考情報＞
WASV7 Feature Pack for Service Component Architecture 1.0.1リフレッシュ版では、Spring
Framework 2.5.5をサポートします。
IBM WebSphere Application Server V7.0 Feature Pack for Service Component Architecture (SCA)
V1.0.1 Open Beta
https://www14.software.ibm.com/iwm/web/cc/earlyprograms/websphere/iwsasfpscaob/index.shtm
l
22
02. フレームワーク
フレームワークの発展
‰
WAS x Spring/Hibernate連携
€
€
‰
～WAS/Hibernate連携
データソース
トランザクション
WAS独自機能の利用が可能
接続プール、トランザクション、分離レベル
ピアリカバリー、タイマー、モニター
Spring x Hibernate連携例
ビジネス層
トランザクショ
ンマネージャー
Session
Factory
DAO
トランザクション開始()
<<intercept>>
Hibernate
RDBMS
トランザクション開始()
新規登録()
セッション取得()
セッション開始()
save()
commit()
<<intercept>>
commit時同期処理()
セッション終了()
insert()
SQLException()
HibernateException()
DBアクセスをDAOレイヤーにて隠蔽
トランザクション境界でHibernateの例外が発生
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
トランザクション境界にインターセプタを
追加して、例外をラップする
23
Springにてデータソースやトランザクションを管理できますが、これらをWASで管理させることを検討
して下さい。WASが提供する接続プール、トランザクション管理、分離レベル設定機能を利用できま
す。また、トランザクションについては、以下のWASが提供している機能を利用できます。WASと
Spring、Hibernateの連携方法については、参考資料の 「WAS × Webフレームワーク連携手法」を
ご確認下さい。
・ピア・リカバリー機能
HAマネージャーによるトランザクションマネージャーのフェイル・オーバー機能です。トランザクション
マネージャー障害時にトランザクションのリカバリーを実施します。
・タイマー機能
トランザクション・タイムアウトが設定可能です。ある一定時間を経過したトランザクションをロールバッ
クします。
・モニター機能
実行トランザクションのスナップショット機能です。実行中やロールバックされたトランザクション数等、
トランザクションの状態をTivoli Performance Viewerでモニターできます。
Hibernateが書込みSQLを発行するタイミングは、クエリで検索を行う時と、Session.flush()を呼び出
した時と、Transaction.commit()を呼び出した時です。そのため一意制約例外や並行性制御例外が
トランザクション境界で発生してしまうことがあります。DBアクセスをDAOレイヤーで隠蔽したとしても、
Hibernateの例外が返ってしまいますので、Springによって例外をラップすることを検討して下さい。
＜参考情報＞
WASV7.0 Information Center 「JTA サポート」
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.nd.m
ultiplatform.doc/info/ae/ae/cjta_extjta.html
＜コラム＞
Hibernate開発者の方も、以下の理由によりRDBMSのスキルがあった方が望ましいと考えます。
・データアクセスはHibernateが裏で勝手に実施してくれるから、開発者は発行されるSQL文を意識
しなくて良いという考えでは、N+1セレクト問題を早期に発見できない。
・開発者がDBインフラ担当者に複雑な検索について相談すると、HQLを知らないDBインフラ担当者
はSQLでその検索方法を答えます。開発者は、そのSQL文をHQLに翻訳しなければいけない。
23
02. フレームワーク
フレームワークの発展
～Beanスコープ
Spring 1.x
<beans>
<beans>id="sample"
id="sample"class=“ise.com..SampleBean“
class=“ise.com..SampleBean“singleton=“false"/>
singleton=“false"/>
デフォルト値は、singleton=“true”
Spring 2.0
<beans> id="sample" class=“ise.com..SampleBean" scope=“prototype"/>
<beans> id="sample" class=“ise.com..SampleBean" scope=“prototype"/>
Spring 2.0で利用可能なスコープ
Spring 2.5
スコープ
@Scope("session")
@Scope("session")
public
publicclass
classShoppingCart
ShoppingCart{ {...}
...}
‰
Spring x Hibernate連携例
Employee
DaoDB2
Injection Spring
A社用
DB
B社用
DB
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
詳細
singleton
アプリケーション開始と終了までのスコープ
prototype
取得されるたびに新しいBeanが作成されるスコープ
request
ServeltAPIのリクエストスコープ
session
ServletAPIのセッションスコープ
globalSession
Portlet APIのグローバルsessionスコープ
singletonでは、意図したDBに
接続できない可能性がある
スコープの設定に注意
マルチスレッド環境で判明する事象がある
24
Spring 1.xまでは、利用可能なスコープがsingletonかprototypeのみでしたが、Spring2.0にて
request / session / globalSessionが追加されました。Beanのライフサイクルの種類が増え、ライフサイ
クルの広いほうから狭いほうを参照できるようになりました。また、独自のライフサイクルの仕組みを作
成することも可能です。
(注意1)
デフォルト値がsingletonの場合、上図のようにDI/AOPによってDB接続先を切り替えている場合、意
図したDBに接続できない可能性があります。また、このような事象はマルチスレッド環境でテストする
必要があります。マルチスレッド環境は、システムテスト等、プロジェクトの後半にならないと実施され
ないケースが多いかと思いますので、事前に確認項目をリストアップされると良いと思います。
(注意2)
sessionスコープを定義したBeanは、セッションタイムアウト/セッション破棄まで残ります。同一session
からマルチスレッドで実行した場合、同期しないと状態が壊れてしまいますので、ご注意下さい。(通
常のセッションと同様です。開発者が意識しないで使用できることが考慮点です。)
＜補足＞
singletonとは、インスタンスが1個しか存在しないことを保証するJ2EEデザインパターンです。
prototypeとは、クラスからインスタンスを生成するのではなく、インスタンスから別のインスタンスを作
成するJ2EEデザインパターンです。下記のようなケースでメリットがあります。
・種類が多すぎてクラスにまとめられない場合
(1つ1つを別のクラスにしていたら、ソースファイルを多数生成する必要が生じてしまう)
・クラスからインスタンス生成が難しい場合
(グラフィックエディタ等でユーザがマウス操作によって作り上げたインスタンス)
・フレームワークと生成するインスタンスを分けたい場合
(インスタンスを生成するときのフレームワークを、特定のクラスに依存しないように作りたい)
24
02. フレームワーク
フレームワークの発展
～Seasar編
‰ Seasar登場の背景、特徴
€
€
‰
J2EEを易しく・優しく
SpringよりLight-weightなコンテナ
„
„
„
より設定ファイルの記述量が少ない
より実用的な仕様
Hot Deploy機能
‰ 主な構成例
€
€
€
S2Struts + S2DAO
SAStruts + S2JDBC
S2Struts(SAStruts) + S2Hibernate
Spring/Seasar選択指針例
‡ 思想
Spring:汎用的な機能を提供するDIコンテナ
Seasar:DIコンテナを中心としたWebアプリ
ケーションフレームワーク
‡ 情報量
日本語はSeasar、英語を含めるとSpring
‡ DIコンテナとしての機能
ほとんど変わらない
‡ 市場
Seasarは日本のみを対象とする
‰ 構成指針例
‡ SQLを書きたい、Daoパターンを好む
→ S2Dao
‡ SQLを書きたい、Javaオブジェクトとテーブルは同一構造で良い → S2JDBC
‡ テーブルに引きずられなく、 Javaオブジェクトをモデリングしたい → S2Hibernate
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
25
Seasarのテーマは「J2EEの解体と再構築、易しさと優しさ」です。J2EEの複雑さを取りのぞき、トラン
ザクション管理や接続プールといったJ2EEの良いところだけを、なるべく軽く、簡単に利用できるよう
にしています。SpringよりもLight-weightなコンテナを目指しています。
SeasarとSpringの選択指針は、DIコンテナの機能としてはほとんど変わらないため、SeasarがDIコン
テナを中心としたWebアプリケーションフレームワークを思想としている点と日本のみをターゲットとし
ている点になるかと思います。また、SeasarはSpringと同様にStrutsやHibernateと連携することができ
ます。主な構成例として、S2Struts + S2DAO、SAStruts + S2JDBC、S2Struts (SAStruts) +
S2Hibernateなどが挙げられます。(詳細は参考資料を参照)
＜参考情報＞
・DTO (Data Transfer Object)
EJBにて開発した場合、リモートとのやり取りのたびに通信が発生するため、パフォーマンスの悪化
を解消するために用いられるJ2EEデザインパターンのひとつになります。このやり取りの回数を減ら
すためにDTOオブジェクトに一度に多くのデータを詰め込んでやり取りを行い、パフォーマンスを向
上させます。DTOはデータを保持するという点に特化しているため、振る舞いを持たないPOJOのク
ラスになります。現在は、EJB以外の場合でも、レイヤー間でデータを受け渡す際に入れ物としての
役割を果たしています。
・Hot Deploy機能
通常のクラス・ローダーは、委譲モデルに従ってクラスのロードを親クラス・ローダーに委ねますが、
Seasarが提供するHotdeployClassLoaderは、未ロードのクラスを親クラス・ローダーに委譲することな
く自分自身でロードします。こうすることで、クラスがアプリケーションサーバーのクラス・ローダーに
ロードされることを防ぎ、リクエスト毎にロードし直しますことで、アプリケーションの再デプロイすること
なく、Javaコードの修正を反映することが可能になっています。再デプロイが発生しないため、待ち
時間の発生やセッション情報の喪失を防ぐことができます。
・WASとSeasarとの連携については、下記リンク先資料をご確認下さい。
http://www.ibm.com/developerworks/jp/views/java/libraryview.jsp?search_by=Seasar2&S_TACT=1
05AGX90&S_CMP=content
25
02. フレームワーク
フレームワークの発展
～Ajax対応
‰ Ajaxアプリケーション開発の課題
€
€
JavaScriptのスキル習得
ブラウザの非互換、非同期通信の実現方法、データ変換(XML or JSON) 等
‰ Ajaxアプリケーション開発フレームワーク
€
DWR (Direct Web Remoting)
„
€
クラス名.メソッド名
JavaScriptからサーバー側のJavaオブジェクトを呼び出す
GWT (Google Web Toolkit)
„
HTML
HTML/ /JavaScript
JavaScript
function
functioneventHandler(){
eventHandler(){
AjaxService.execute(callback);
AjaxService.execute(callback);
}}
Javaで作成したクライアントアプリケーションを、
JavaScript＋HTMLアプリケーションに変換する
function
functioncallbackr(data){
callbackr(data){
dwr.util.setValue(“result”、data);
dwr.util.setValue(“result”、data);
}}
‰ 選択指針例
€
メッセージ：Hello DWR!
JavaScript開発の難しさ
JavaScriptで開発するか? Javaで開発するか?
DWR：
„
GWT：
„
Java経由により開発速度、柔軟性、表現力が犠牲になる
JavaScriptよりJavaで開発する方が、質の良いコードが書ける
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
26
Ajax (Asynchronous JavaScript + XML)とは、名前が示す通りJavaScriptで作成されたブラウザー
上で稼動するアプリケーションです。JavaScriptやCSS、HTMLのみを使用してリッチなユーザーイン
ターフェースを作成します。また、画面表示後は画面全体ではなく必要な部分のみ書き換えることに
より、アプリケーションの画面遷移をよりユーザーが使い易い様に設計することが可能です。部分的
なデータの送受信には、HTTPプロトコルを用い、データフォーマットはXMLかJSONを使用すること
が多いです。
Ajaxアプリケーションを開発するためには、JavaScriptに関するスキルを取得しなければいけない、
ブラウザの非互換性を解決しなければいけない、非同期通信の実現方法、サーバーとクライアント
間のデータ変換方法(XML or JSON)等を検討する必要がありました。
DWRは、JavaScript－Java連携用フレームワークです。Ajax独特の複雑なJavaScriptを必要とせず、
JavaScript内で「クラス名.メソッド名」と記述することによって、Javaの該当メソッドを透過的に呼び出
すことが出来ます。DWRはわかりやすいことに加えて、様々なフレームワークとの連携が容易である
ため、スクラッチでJavaScriptを大量にコーディングしたり、GWT (Google Web Toolkit)のようにガチ
ガチにフレームワークに縛られることに抵抗感を覚えるJava技術者にとって、最適なフレームワークと
言えます。
GWTは、クライアントアプリケーションをJava言語で作成し、それをJavaScript＋HTMLアプリケー
ションに変換するというフレームワークです。言い換えますと、Ajaxアプリケーション開発の際に
JavaScriptを書く必要がありません。
そのDWRとGWTの選択指針は、一概には言えませんが、「Javaで開発するか、JavaScriptと開発す
るか？」で判断できるかと思います。GWTを使用するメリットとしてJavaScriptよりJavaで開発すること
により、質の良いコードを書くことができます。もちろん、スキルフルなJavaScript技術者であればその
限りではありませんが、Java開発よりエラーメッセージの意味がわかりにくく、テスト(jsUnit等)の準備
作業が大変です。反対に、Javaで開発することにより、軽量プログラミング言語(JavaScript)の特徴で
ある開発速度、柔軟性、表現力が犠牲になります。
26
02. フレームワーク
Java EE 5におけるフレームワーク選択指針
MVC
フレームワーク
‡ 標準重視 or オープン技術
－ JSFは標準、Strutsはオープンソース
‡ 成熟度・実績
－ 実装の成熟度・実績では、(かなり)Strutsがリード
‡ StrutsとJSFの共存、Facelets / Myfaces (JSFの開発生産性向上と機能拡張)
O/Rマッピング
フレームワーク
‡ 標準重視 or オープン技術
－ JPAは標準、Hibernate/iBATISはオープンソース
‡ 成熟度・実績
－ 実装の成熟度・実績では、(若干)Hibernateがリード
－ HibernateとEJB 3.0(JPA)は機能的に非常に類似
‡ SQLの生成
－ SQL文をより自由にチューニングしたい場合に、iBATISが向いている
DI / AOP
フレームワーク
‡ 標準重視 or オープン技術
－ EJB3.0は標準、Spring/Seasarはオープンソース
‡ 成熟度・実績
－ 実装の成熟度・実績では、Springがリード
‡ 分散システムの構築
－分散システムを構築する場合は、EJB 3.0
・標準を重視するか、実績のあるオープン技術を選択するかを念頭に置き、
プロジェクト要件とフレームワークの特性を突き合わせる
・Java EE 5では、JSF/EJB/JPAが十分な選択肢である
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
27
Java EE 5のフレークワークの選択指針をまとめたチャートになります。また参考資料にて、フレーム
ワーク毎に特徴やメリット/デメリット等をまとめていますので、合わせてご確認下さい。
Java EE 5におけるフレームワークの選択指針は、JDK1.4と同様に、「標準を重視するか、実績の
あるオープン技術を選択するかを念頭に置き、プロジェクト要件とフレームワークの特性を突き合わ
せる」ではないかと思います。JDK1.4と異なるのは、JSF/EJB/JPAが十分な選択肢となったことです。
アーキテクチャーだけを考慮すれば、オープンソースよりも優れている標準のフレームワークもありま
す。また、今後はより標準とオープンソースのフレームワークを組み合わせた事例が増えていくので
はないかと推測します。
＜補足＞ ：JSFとStruts
JSFは概念的にはStrutsと同等の機能を持ち、 より洗練された優れたアーキテクチャになっている
と言えます。 (JSFのスペックリードをStrutsを開発したCraig McClanahan氏が務めています。)また、
JSFをStrutsのフロントエンドとして利用し，ビジネスロジックの呼び出しやフロー制御はStrutsを利用
することも可能です。
主な違いは、JSFはPOJOベースの実行環境である点です。Strutsでは、HTMLフォームに入力さ
れたHTTPパラメータは、 StrutsのActionFormサブクラスのプロパティに格納されます。 そして、プレ
ゼンテーション層とビジネス層を疎結合にするため、 ActionFormのプロパティをPOJOなバリュー・オ
ブジェクトに移し替えてから、 ビジネス・メソッドの引数とするのが一般的です。 一方、JSFは、HTML
フォームを構成するJSP上の入力コンポーネントから、 JSF-EL を使用して、 直接POJOなオブジェク
トのプロパティに入力値を設定することができます。 また、Strutsを採用するとデファクトスタンダード
であるがゆえに他社との差別化が難しい、バージョンアップ時の互換性の保証がないという懸念点も
あります。(しかし、現状としては、あまりJSFの実績はありません。)
入力フォームのページに入力パラメータが数十個あったとすると、StrutsのActionFormでは数十個
のsetter / getterがずらりと並ぶ数百行のソースコードになります。そのため、場合によっては、
ActionFormのパラメータをきれいなビジネス・オブジェクトのツリー構造に変換するためのフレー ム
ワーク開発が別途必要になります。JSFのページの場合はこのようなオブジェクトマッピングのための
追加開発は必要なく、JSF-ELのバインディング を定義するだけで、複雑なオブジェクト・ツリーへの
変換が可能です。また、JSFの実行環境は、セッター・インジェク ションに限定されますが、DIコンテ
ナとしての機能を持っています。ビジネス層の入出力となるオブジェクト・ツリーとアクション・メソッドを
含むバッキン グ・ビーンとの依存関係は、JSF設定ファイルのタグで依存性の注入を行うことができま
す。
27
02. フレームワーク
2～3年後を見据えたフレームワーク選択指針
解決されていないフレームワークの課題
€
€
€
€
XML設定ファイルの更なる簡便化
複数のフレームワーク連携による、XML設定ファイル地獄
フルスタックフレームワークによる、パフォーマンスの劣化
開発コストの削減
Contexts and
Dependency Injection
Java EE 6
Slim3
vCloud
Seasar
VMware / Spring
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
28
続いて、2～3年後を見据えたフレームワークの選択指針を考えます。Java EE 5時代でも解決され
ていないフレームワークの課題として、XML設定ファイルの更なる簡便化があります。また、そもそも
複数のフレームワークを連携するからXML設定ファイル地獄が発生すると考えられ、フルスタックフ
レームワークが解決策なのですがパフォーマンスが悪くなるという別の問題が発生してしまいます。
また、いつの時代でも出来る限り開発コストを削減したいという要望があります。
この課題を解決するキーワードが「軽量フルスタック」と「クラウド」になり、そのキーワードを実現す
るテクノロジーが、「Contexts and Dependency Injection」と「Slim 3」、「vCloud」ではないでしょうか。
＜参考情報＞
・Amazonの提供するWebサービス群(Amazon EC2/S3/EBS/SQS)をEclipseから利用するためのツー
ルを提供するプロジェクト
http://sourceforge.jp/projects/eclipse-aws/
・Myfacesの主な機能 (JSFのオープンソースによる実装)
- 画面遷移をビジュアルに構成できるグラフィカル・ナビゲーション・フロー・デザイナー
- faces-config.xmlファイルのソースを直接編集できる拡張XML ソース・エディター
- faces-config.xmlファイルの構成要素の種別ごとに構成できるFaces構成エディター
- faces-config.xmlファイルの各構成要素を簡単に構成するための様々なウィザード
・Faceletsの主な機能 (JSFを作成するためのフレームワーク )
- JSF 1.1とJSF 1.2をサポート
- テンプレートの作成と利用(Tilesのように)
- 合成コンポーネント
- カスタムロジックタグ
- ELファンクション
- デザイナーフレンドリーなページ開発
- コンポーネントライブラリの作成
- Webコンテナに依存しない
28
02. フレームワーク
軽量フルスタック・フレームワーク
‰ Contexts
€
€
and Dependency Injection
Java EE 6にて取り込まれるフルスタックのWebアプリケーションフレームワーク
JBoss Seamにより実現されているJSF、EJB、JPAの統合 (JSR-299)
„
Java EEの統合コンポーネントモデル
„
疎結合かつ、厳密な型システムの提供
ステートフルなコンテキストの扱い
„
JSP
POJO
€
POJO
@NAME (“xxx”)
@NAME (“xxx”)
JSF
‰ Slim3(Simple
POJO
NAME
EJB
Java EE 6
and Less Is More)
JPA
アノテーション
による連携
アジャイルな開発のためのフルスタックのWebアプリケーションフレームワーク
„
„
„
Hot deployment
Less configuration
Less Learning Cost
Slim3 Struts
Slim3 JDBC
Struts
JDBC
Slim3 Container
Spring
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
≒SAStruts
設定ファイルの必要がない
Seasar Hot Reload機能
Spring設定ファイル
トランザクション管理、接続プール
→Spring機能
29
「Java EEに統合されたコンポーネントモデル」
いくつかのアノテーションを使うだけでEJBとJSFをつなぎ合わせることができるのが、特徴です。
「疎結合を目指しながら、厳密な型システムを提供する」
アノテーションやメタアノテーションにより、型の安全性を犠牲にすることなく疎結合を実現します。
「ステートフルなコンテキストの扱い」
今までのJava EEでは、ステートレスなサービスかスコープに状態を保持するのが主流でしたが、複
数のリクエストに渡って状態を保持できる対話 (Conversation) コンテキストがあります。
「HOT deployment(生産性向上)」
アプリケーションサーバを稼働させたままソースコードの修正が即座に反映される機能です。Rubyな
どのLLと同様に迅速な開発が可能になり、生産性が大きく向上します。
「Less configuration(少ない設定)」
CoC (Convention over Configuration)とアノテーションの組み合わせによって設定ファイルを減らし
ます。コードの書き方などで規約を守っていれば、フレームワークが自動で設定を行ってくれます。
CoCを使うと設定ファイルが減りますが、多用すると規約を知らない人には分かりづらく、生産性も上
がらないという面もあります。また、Java EE 5のアノテーションの流行により、 1行のコードにいくつも
のアノテーションを定義しアノテーション地獄が発生しています。
「Less Learning Cost(少ない学習時間)」
Struts 1.2系の上に「Slim3 Struts」が、JDBCの上に「Slim3 JDBC」が、DI/AOPコンテナとしてSeasar
ではなくSpringの上に「Slim3 Container」が乗る構成になっています。Slim3 StrutsはSeasar2の
SAStrutsに近いイメージです。Strutsを使いつつ、struts-config.xmlなど面倒な設定ファイルを定義
する必要がありません。Slim3 Containerは、Seasar2から設定ファイルをなくしたイメージになり、設定
ファイルを使う場合はSpringの機能を使うことができ、 Seasar2のHot Deploy (Reloading)機能を搭載
しています。ユーザーからの変更が入りやすい要件は、HOT Deploy機能によってSlim3 Container
上のコンポーネントとして動かします。トランザクション管理やコネプションプール管理など非機能要
件は、Springをそのまま使うことが想定されています。
29
02. フレームワーク
クラウド対応フレームワーク
開発環境クラウド化によるコスト削減
€
€
構築コストの低下、構築時間の短縮
リソース・ニーズの有効活用
‰ Slim3
€
€
Application
Middleware
OS
Hardware
(Simple and Less Is More)
Google App Engineに最適化した
Webアプリケーションフレームワーク
‰ V-Cloud
€
PaaS
→ PaaSソリューション
クラウド・サービス間の相互運用性を実現するAPI
DMTF (Distributed Management Task Force)
„
オープンクラウドインキュベーターに提出
V-Cloud
Public Cloud
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
Private Cloud
30
IaaS (Infrastructure as a Service)は、CPUやストレージをクラウド基盤に配置し、サービスとして提
供します。Amazon® EC2やAmazon® S3が当てはまります。Paas (Platform as a Service)は、アプリ
ケーション稼動プラットフォームをクラウド基盤に配置し、サービスとして提供します。Force.com、
Google® App EngineやWindows Azureが当てはまります。
・ DMTF
システム運用管理のためのH/W、S/W等のインタフェース標準化活動を行う国際的な業界団体。
・VMotion
稼働中の仮想マシンを停止させることなく、しかもクライアントからのセッションも維持したまま、別の
VMware ESX Server上に移動させる技術のこと。
・Developer: VMware vCloud™ API
http://communities.vmware.com/community/developer/forums/vcloudapi
VMware vCloud API は、vCloud 構想の幅広いアプリケーションとサービス プロバイダの相互運用
性を支えています。この API は、プライベート クラウド リソースへのプログラムからのアクセスを可能
にし、既存のプライベートクラウドを活用するサービスとアプリケーションの提供をサポートしています。
Public/Privateクラウドの両方で、より効率的なアプリケーションの開発、実行、管理が可能に
【2009 年 9 月 16 日 (米国時間)米カリフォルニア州発】 VMware, Inc. (NYSE： VMW) は2009 年 8
月10 日に買収を発表したエンタープライズおよび Web アプリケーション開発・管理のリーディング
企業、SpringSource の買収が正式に完了したことを発表します。今回の買収完了により、
SpringSource は、VMwareの一部門となり、SpringSourceの創業者でCEOであるRod Johnson氏 が
ジェネラル マネージャとして本部門を統括します。この新しい部門では、あらゆるプラットフォーム上
の企業向けアプリケーションやWebアプリケーション開発者に対して、引き続き最も優れた環境を提
供していくことに注力していきます。また、それに加えVMwareはSpringSourceの技術とVMware
vSphere™との組み合わせにより、容易に「開発、実行、運用」可能な統合製品の開発を推し進めて
いきます。これらの新製品は、VMwareの戦略である顧客のデータ センターまたはサービス プロバイ
ダの施設でホストされるプラットフォームをサービスとして提供する、PaaSソリューションをさらに拡大
するものです。
30
02. フレームワーク
Rod Johnson氏
‰
‰
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
Spring Frameworkの開発者
VMWare社 ジェネラルマネージャー
31
31
02. フレームワーク
３．Java EE 6
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
32
フレームワークのセッションで、Java EE 6が説明されることに疑問を持たれた方もいらっしゃるかと
思います。ご説明する理由は、小規模のサンプルアプリケーションをJava EE 6にて作成してみたとこ
ろ、Contexts and Dependency Injectionを含めて、Java EE 6が今後のフレームワークのデファクトス
タンダードになる可能性を感じたからです。今までは、Struts/Spring/Hibernateがフレームワーク選
定の前提であるケースが多かったかと思いますが、 今後はJava EE 6が前提で足りない機能をオー
プンソース・フレームワークで補完するという時代が来てもおかしくないと推測致します。
32
02. フレームワーク
Java EE 6の方針
Proposed Final Draft
‰ サイズの適正化
€
Web Profile (柔軟性)
„
€
JSF2.0
JSP2.2
Java EE完全版に対するサブセット版
Pruning (軽量化)
EL2.2
Servlet3.0
EJB3.1
Lite
„
Java EE 6での削除候補
„
次期版(Java EE 7)で、“削除”、”必須”、”削除提案のまま”を決定
z
JSTL2.2
JPA2.0
JTA1.1
BeanValidation
1.0
JSR 316: JavaTM Platform, Enterprise Edition 6 (Java EE 6) Specification
EJB 2.X Entity Beans、JAX-RPC、JAXR、JSR-88(Java EE Application Deployment)
‰ 拡張性
€
オープンソースフレームワーク受容
„
web.xml のモジュール化 (web fragment)
‰ 使い勝手、開発しやすさの追及
€
Java EE 5からの継続的な進化
„
„
アノテーションを活用したプログラムモデル
DDの必要性を削減・削除する
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
Lite版
Lite版
・・Local
LocalSession
SessionBeans
Beans
・・Annotations
Annotations/ /ejb-jar.xml
ejb-jar.xml
・・CMT
CMT/ /BMT
BMT
・・Declarative
DeclarativeSecurity
Security
・・Interceptors
Interceptors
・・JPA
JPA2.0
2.0
・・JTA
JTA1.1
1.1
完全版=Lite版+α
完全版=Lite版+α
・・Message
MessageDriven
DrivenBeans
Beans
・・EJB
EJBComponent
ComponentWeb
Web
Service
ServiceEndpoints
Endpoints
・・RMI-IIOP
RMI-IIOPInteroperability
Interoperability
・・2.x/3.x
2.x/3.xRemote
RemoteView
View
・・2.x
2.xLocal
LocalView
View
・・Timer
TimerService
Service
・・CMP
CMP/ /BMP
BMP
33
・プロファイル (柔軟性)
アプリケーションの特定の分類をターゲットとしたJava EE プラットフォームの構成です。Java EE 完
全版に対するサブセット版であり、JSR-316で、Web Profileを規定されます。
・オープンソースの受容
web.xml のモジュール化(web fragment)
ライブラリ・フレームワーク開発者は、必要があればweb-fragment.xml を用意します。(jar内の
META-INFディレクトリ内)。アプリケーション開発者は、自分で開発したコードに関する設定だけを
行い、利用するライブラリ・フレームワークのjarをWeb-INF/lib 内に置きます。Webアプリケーション・
サーバがweb-fragment.xml の検索、その内容の走査を行い、最終的な配布記述子にマージします。
これにより、Java EE 6のフレームワークのセットアップは、WEB-INF/libフォルダにjarファイルを置く
だけになります。デフォルトのマッピングであれば環境設定の必要がなく、環境設定ファイルを用意
したりサービスローダーを使用すればカスタマイズしたマッピングが可能です。
Java EE6のプログラムコードの記述・構文については検討中のものであり、確定ではありませんので
ご注意下さい。
33
02. フレームワーク
主な構成要素の追加/変更点
‰ Contexts
€
JSF、EJB、JPAの統合
‰ Bean
€
Validation 1.0 (JSR-303)
新規アノテーションを利用したバリデーション
‰ JAX-RS
€
and Dependency Injection 1.0 (JSR-299)
1.0 (JSR-311)
@Null、@NotNull、@AssertTrue、
@Null、@NotNull、@AssertTrue、
@AssertFalse、@Min、@Max、
@AssertFalse、@Min、@Max、
@DecimalMin、@DecimalMax、
@DecimalMin、@DecimalMax、
@Size、@Digits、@Past、
@Size、@Digits、@Past、
@Future、@Pattern
@Future、@Pattern
RESTful Web Service に対応
‰ JSF
2.0 (JSR-314)
‰ Servlet3.0 (JSR-315)
€
アノテーションによる宣言的プログラミング
‰ JPA
€
2.0 (JSR-317)
O/Rマッピングの拡張、Criteria API
‰ EJB3.1
€
WASV7
WASV7Feature
FeaturePack
Packfor
forJPA2.0
JPA2.0
(JSR-318)
war内へのパッケージング、シングルトン、非同期、組込み可能なEJBコンテナ
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
34
Bean Validationにより、Java Beanのプロパティが取り得る値の範囲や条件を設定し、実行時に統
一的な方法でそれを検証できるようになります。これにより、WebアプリケーションやGUIアプリケー
ションの入力値検証や、オブジェクトの永続化の際のデータ検証などが容易に行えるようになります。
数値プロパティの最大値/最小値の指定や、文字列の長さやフォーマットの指定などが含まると推測
されます。また、このような機能を提供するフレームワークはすでにいくつか実在しており、JSR 303の
仕様もそれらの影響を受けているかと思います。
＜参考情報＞
・IBM WebSphere Application Server V7 Java Persistence API (JPA) 2.0 Open Alpha
https://www14.software.ibm.com/iwm/web/cc/earlyprograms/websphere/wsasjpaoa/index.shtml
Feature Packとは、WASに最新の機能を追加してくれるパッケージです。これは、WASの機能拡張
であるので、WASのライセンスのみで使用可能で、サポートも同様に行われます。 FP for Web
Services、FP for EJB 3.0、FP for Web 2.0等が公開されています。また、FP for JPAが予定されてい
ます。
・Bean Validationサンプル
@Entity
public class Employee implements Serializable {
private Long id;
@NotNull @Length(min=0,max=80) ←最小値と最大値の指定
private String name;
@NotNull ←NotNullの指定
private Address address;
}
Hibernate Validator：https://www.hibernate.org/412.html
JSR 303 Bean Validation：http://jcp.org/en/jsr/detail?id=303
34
02. フレームワーク
Javaの歴史
Rightsizing
Ease of
Development
Web Services
Enterprise
Java
Platform
J2EE 1.2
JPE
Project
・Servlet
・JSP
・EJB
・JMS
・RMI/IIOP
Robustness
J2EE 1.3
・CMP
・Connector
Architecture
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
J2EE 1.4
・Web Services
Management
・Deployment
・Async
Connector
Java EE 5
・Ease of
Development
・Annotations
・EJB 3.0
・Persistence
・New and
Updated
Web Services
Java EE 6
・Pruning
・Extensibility
・Profiles
・Ease of
Development
・EJB Lite
・RESTful
Services
・Dependency
Injection
・WebProfiles
35
35
02. フレームワーク
EJB Packaging
‰ Java
EE 6 / EJB 3.1
EJBSample.war
WEB-INF/classes/
com/ise/EJBSampleServlet.class
com/ise/EJBSampleBean.class
‰ Java
EE 5 / EJB 3.0
EJBSample.ear
EJBSample.ear
EJBSample_web.war
lib/EJBSample_common.jar
WEB-INF/web.xml
WEB-INF/classes/
com/ise/EJBSampleServlet.class
com/ise/EJBSample.class
com/ise/EJBSample.class
EJBSample_ejb.jar
com/ise/EJBSampleBean.class
com/ise/EJBSample.class
EJBSample_web.war
OR
WEB-INF/web.xml
WEB-INF/classes/
com/ise/EJBSampleServlet.class
EJBSample_ejb.jar
com/ise/EJBSampleBean.class
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
36
36
02. フレームワーク
EJB 3.1新機能
‰ シングルトンSession
€
Bean (@Singleton)
アプリケーションレベルで一度だけ初期化される
‰ カレンダー表記のタイマー
// Every weekday at noon
// Every weekday at noon
ScheduleExpression expr = new ScheduleExpression().dayOfWeek(“Mon-Fri”).hour(12);
ScheduleExpression expr = new ScheduleExpression().dayOfWeek(“Mon-Fri”).hour(12);
timerSvc.createTimer(expr, null); }
timerSvc.createTimer(expr, null); }
UNIXのcronに類似
‰ 自動生成タイマー
€
€
配置時にコンテナがタイマを自動的に生成
@Schedule アノテーションの追加
„
„
@Schedule(dayOfWeek=”Mon”)
@Schedule(minute=”15”, hour=”3”, dayOfWeek=”Mon-Fri”)
‰ 非同期処理
// 毎月曜日深夜0:00
// 月～金の午前3:15
(@Asynchronous)
@Local public interface EmployeeHandler {
@Local public interface EmployeeHandler {
@Asynchronous
@Asynchronous
public void processEmployee(Employee Employee); }
public void processEmployee(Employee Employee); }
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
EJBで非同期呼び出し
ローカルインターフェースにて指定
37
EJB3.1の新機能として、シングルトンSession Beanが追加されます。シングルトンという名前の通り、
アプリケーションレベルで一度だけ初期化されます。(サンプルは、参考資料をご確認下さい。)その
他に、カレンダー表記および自動生成のタイマー機能が追加されます。上記のようにUNIXのcronに
似た文法で、スケジュールを設定することができます。また、@Scheduleアノテーションにてスケ
ジュールを設定することができます。これらは、JBoss Seamの考え方が取り入れられていると推測で
きます。
37
02. フレームワーク
Servlet 3.0新機能
‰
@WebServlet、@WebFilter、@WebInitParam、 @MultipartConfig
@WebServlet( name=“mytest”, urlPatterns = {“/myurl”}, initParams = { @WebInitParam (name="n1", value="v1"))
@WebServlet( name=“mytest”, urlPatterns = {“/myurl”}, initParams = { @WebInitParam (name="n1", value="v1"))
public class TestServlet extends javax.servlet.http.HttpServlet {
public class TestServlet extends javax.servlet.http.HttpServlet {
初期パラメーター
public void doGet(HttpServletRequest req, HttpServletResponseres res) { ... }
public void doGet(HttpServletRequest req, HttpServletResponseres res) { ... }
}
}
@WebServlet("/upload")
@WebServlet("/upload")
@MultipartConfig(maxFileSize=10)
@MultipartConfig(maxFileSize=10)
public
publicclass
classNewServlet
NewServletextends
extendsHttpServlet
HttpServlet{ {…
…
‰ Servlet、Filterの動的登録
サイズ制限
ファイルアップロード処理
/ 動的検索(Lookup)
ServletRegistration.Dynamic dynamic = servletContext.addServlet ("MyServlet");
ServletRegistration.Dynamic dynamic = servletContext.addServlet ("MyServlet");
dynamic.addMapping ("/MyServlet");
dynamic.addMapping ("/MyServlet");
‰ 非同期処理用のAPI
€
€
€
€
ServletRequest
AsyncContextServletRequest
AsyncContext
AsyncListener
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
38
Servlet 3.0ではEoDをさらに促進するため、ServletやFilterなどを定義するためのアノテーションが
用意される予定となっています。これにより、コードの記述量の削減やweb.xmlなどに対する設定の
簡略化が実現されます。
@WebServlet – Define a Servlet
@WebFilter – Define a Filter
@WebListener – Define a Listener
@WebInitParam – Define init params
@MultipartConfig – Define fileupload
Can use web.xml to override values specified in the annotations
・非同期処理用のAPI
ServletRequest isAsyncSupported(), setAsyncTimeout(long)
AsyncContextServletRequeststartAsync(), startAsync(ServletRequest, ServletResponse)
AsyncContextdispatch(), dispatch(String), complete()
AsyncListenerOnTimeout(AsyncEvent), OnComplete(AsyncEvent)
＜コラム＞
Java EE 6ではJava EE 5と同様に、アノテーションを活用して設定ファイルを削減・削除する流れに
なっています。Servlet2.5にて@Resourceが追加され、データソース等のリソース参照をweb.xmlに定
義する必要がなくなりました。Servlet3.0では@WebServletが追加され、サーブレットマッピング情報
をweb.xmlに定義する必要がなくなりました。アノテーション地獄という言葉が出てきていますが、必
ずしも全てのケースでアノテーション化することがより良いと限りません。運用、メンテナンスを考慮し、
何をアノテーションで定義し、何をweb.xmlで定義するかの開発標準を制定することが重要になると
思います。
38
02. フレームワーク
４．まとめ
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
39
39
02. フレームワーク
フレームワーク 選択指針 まとめ
‰ Java
€
€
EE 5における選択指針
標準を重視するか、実績のあるオープン技術
JSF / EJB / JPAも十分な選択肢である
JSP
POJO
POJO
POJO
NAME
@NAME
(“xxx”)
@NAME
(“xxx”)
JSF
EJB
JPA
Java EE 6
‰ 2～3年後の見据えた選択指針
€
€
軽量フルスタック
クラウド
Contexts and Dependency Injection
Slim3
vCloud
‰ Java
€
EE 6
今後のスタンダードとなる可能性を秘めている
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
VS
Slim3 Struts
Slim3 JDBC
Struts
JDBC
Slim3 Container
Spring
VS
V-Cloud
Public Cloud
Private Cloud
VMware / Spring
→ PaaSソリューション
40
40
02. フレームワーク
参考資料
‰ WAS
V6.1 Feature Pack for EJB 3.0 ワークショップ
http://www.ibm.com/developerworks/jp/websphere/library/was/was61_ejb3fep_ws/
‰ WAS
Feature Pack for Web2.0 ワークショップ
http://www.ibm.com/developerworks/jp/websphere/library/was/was_web20fep_ws/
‰ WebSphere
Application Server 最新動向ワークショップ
http://www.ibm.com/jp/software/websphere/developer/was/wv61/workshop/
‰ Using
Spring and Hibernate with WebSphere Application Server
http://www.ibm.com/developerworks/websphere/techjournal/0609_alcott/0609_alcott.html
‰ Developing
Hibernate applications for use with WebSphere
Application Server
http://www.ibm.com/developerworks/websphere/techjournal/0409_patil/0409_patil.html
‰ WAS
× Webフレームワーク連携手法
http://www.ibm.com/developerworks/jp/websphere/library/was/was61_framework/2004.html
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
41
41
02. フレームワーク
参考資料
～フレームワークの種類
過渡的な状況
‰ MVCフレームワーク
„
JSF、Struts、Tapestry、Shale、Velocity
‰ O/Rマッピングフレームワーク
„
JSF
Servlet/JSP
Hibernate、JPA、iBATIS 、TopLink
‰ DI/AOPフレームワーク
„
Spring、Seasar
‰ 機能に特化したフレームワーク
€
パフォーマンス (ページング)
„
JDBC
€
セキュリティー
„
€
S2Pager
Spring Security (Acegi)
Javaバッチ
„
Spring Batch、TERA
EJB
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
42
Java EEが提供している標準のフレームワーク、 オープンソースのフレームワーク、さらにはIBMの
WACsやNRI様のObjectWorksと言ったベンダーが提供している有償のフレームワークがあります。
まさに過渡的な状況にあり、次世代のより洗練されたフレームワークが台頭し始めようとしています。
また、Wikipediaでは数十のフレームワークが存在していることが確認できます。
より特定の機能に特化したフレームワークもあります。例えば、ページングとは、データベースの検
索結果等に対して、1ページに表示する件数を制限し1アクセスのデータ量を削減することができる
機能になります。この機能は、S2Pagerというフレームワークによって提供されています。(アプリケー
ションで対応する場合、DB2：rownumber()/over ()、Oracle：RowNoを実装する必要があります。S/W
で対応する場合、DB2ワークロード管理機能を実装する必要があります。)セキュリティーでは、
Spring Securityというフレームワークによって、認証・認可の仕組みが提供され、セキュリティーに関
するコーディング量を削減することができます。Javaバッチは、オープンソースフレームワークでは長
い間空白域でしたが、Spring BatchやTERA、JBeX(IBMアセット)などが登場しています。(WACsV6.0
にてJbexを取り込んでいます。)
＜参考情報＞
・Wikipedia - 「Comparison of web application frameworks」
http://en.wikipedia.org/wiki/List_of_web_application_frameworks
・S2Pager
http://s2dao.php5.seasar.org/pager.html#S2Pager
・Spring Security概要
認証：FORM 認証、SHA-1/MD5 などのアルゴリズムで暗号化されたパスワードとの照合、RDBMS
による認証情報の管理、 認証後の旧セッションの破棄，および新セッションの生成
認可：ロール/時間によるURL毎のアクセス制御、 認証されていないユーザのアクセス制御
その他：セッションタイムアウト時のハンドリング
・Acegi を使って Java アプリケーションをセキュアにする
https://www.ibm.com/developerworks/jp/java/library/j-acegi1/
42
02. フレームワーク
参考資料
～フレームワーク解説
‰ MVCフレームワーク
„
画面遷移や入力値チェック等、Webアプリケーション基本機能
MVCアーキテクチャーに従って、必要な機能を提供
コンポーネント間の独立性により、生産性・保守性が向上
Model部分や基盤部分に他フレームワークの利用や作りこみが必要
„
プレゼンテーション部分の開発生産性向上のための仕組みが必要
„
„
メリット：
考慮点：
„
‰ O/Rマッピングフレームワーク
„
„
メリット：
考慮点：
„
„
„
„
オブジェクトとリレーショナルデータベース間のマッピング手法
DBとマッピングされたJavaオブジェクトを操作し、データにアクセス
マッピング作業の自動化により、生産性・保守性が向上
異なるRDBMSによるSQLの違いを吸収
パフォーマンス・チューニング時にSQLを意識する必要がある
内部的に発行しているSQLはチューニングができない場合がある
‰ DI/AOPフレームワーク
„
メリット：
„
„
考慮点：
„
„
組み合わせ例
‹
MVCのみ
‹
MVC+O/Rマッピング
WACs、Struts
JSF + Hibernate
‹
MVC+DI/AOP
Struts + Spring
‹
MVC+DI/AOP+OR
Struts + Spring + Hibernate
DI/AOPの機能を統合した基盤フレームワーク
コンポーネント間を疎結合としPOJOとすることで、保守性・再利用性が向上
設定ファイルの外部化、コンポーネント間管理が複雑になる
実行時までバインディングが正しいかどうか確認できない
AOPを使用した場合は、パフォーマンスを考慮する必要がある
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
43
43
02. フレームワーク
参考資料
～フレームワーク選定の考え方
プロジェクト要件
フレームワーク特性
前提条件
・動作環境
・コスト
・サポート状況
・フレームワークの前提
前提条件
・開発期間
・開発プロセス
・スキル
・契約
・環境
提供機能
・画面フロー制御
・入力チェック
・トランザクション制御
・ログ出力
・DBアクセス
非機能要件
・パフォーマンス
・セキュリティー
・運用 / 障害
機能要件
・アプリケーション
・データ
フレームワーク
選定
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
その他
・アーキテクチャー
44
フレームワークを選定する場合には、プロジェクト要件とフレームワーク特性を突き合わせることが
重要になります。
＜前提条件＞
提供形態： ソース・コードが提供されるのか
動作環境： フレームワークの稼動条件(OS、Webアプリケーション・サーバー、RDBMS)
実績： 適用事例の規模／件数
コスト： ランタイム・ライセンス、開発ライセンス、開発ツールの使用料
サポート： ソフトウェア保守、導入サポート、技術サポート、研修、提供ドキュメント、 サポート期間
生産性向上のためのアセット提供： 開発ツールや業務パッケージや、仕様書テンプレートの提供
開発手法：開発プロセスの規定、必要スキル、 開発に必要となるスキル
ライセンス条件： アプリケーションの著作権、展開時の条件、カスタマイズ時の条件
44
02. フレームワーク
参考資料
～フレームワークの特性
基本機能
基本機能
‹
‹
‹
‹
‹
‹
‹
‹
‹
‹
‹
‹
‹
‹
プレゼンテーション層
プレゼンテーション層
(MVCフレームワーク)
(MVCフレームワーク)
‹
‹
‹
‹
‹
‹
‹
‹
‹
‹
‹
‹
‹
‹
‹
‹
‹
‹
‹
‹
‹
‹
‹
‹
その他
その他
ログ・トレース
ログ・トレース
メッセージ・カタログ
メッセージ・カタログ
サービス開閉
サービス開閉
セキュリティー(認証、認可)
セキュリティー(認証、認可)
起動時の初期化
起動時の初期化
終了時の終了処理
終了時の終了処理
例外処理
例外処理
リクエストと処理のマッピング
リクエストと処理のマッピング
画面フロー制御
画面フロー制御
複数ウィンドウへの対応
複数ウィンドウへの対応
入力チェック
入力チェック
ファイル送受信
ファイル送受信
入出力データ変換
入出力データ変換
流量制御
流量制御
ライブラリー
ライブラリー
ページング
ページング
レイアウト機能
レイアウト機能
国際化対応
国際化対応
マルチ・クライアント対応
マルチ・クライアント対応
‹
‹
‹
‹
‹
‹
‹
‹
機能制約
機能制約 (2PC処理、クラスター環境)
(2PC処理、クラスター環境)
テスト容易性
テスト容易性
開発生産性
開発生産性
移行容易性
移行容易性
ビジネス層
ビジネス層
(DI/AOPフレームワーク)
(DI/AOPフレームワーク)
‹
‹トランザクション制御
トランザクション制御
‹
‹ ビジネス・ロジック・テンプレート
ビジネス・ロジック・テンプレート
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
インテグレーション層
インテグレーション層
O/Rマッピングフレームワーク
O/Rマッピングフレームワーク
‹
‹
‹
‹
‹
‹
‹
‹
‹
‹
DBアクセス
DBアクセス
メッセージング機能
メッセージング機能
メール送信機能
メール送信機能
帳票出力機能
帳票出力機能
外部接続機能
外部接続機能
45
45
02. フレームワーク
参考資料
S2Struts + S2DAO
～Struts/Seasar特徴比較
SAStruts + S2JDBC
S2truts(SAStruts) + S2Hibernate
コンセプト
SQLが中心
Entityとテーブルが同一モデル
Entityが中心
SQL生成
検索処理は開発者が作成
挿入/更新/削除は自動生成
複雑なSQL以外は自動生成
Hibernateから継承やLazyロードな
どの機能を削除
ほとんどのSQLが自動生成
メリット
SQLを開発者が書くため、トラ
ブルが発生しにくい
学習コストが低い
SQLをほとんど書かなくてよい
同一モデルなので、インピーダンスミ
スマッチが発生しにくい
Hibernateと比較して、マッピングの
仕様がシンプルで学習コストが低い
機能が限定されているため、トラブル
が発生しにくい
機能が豊富である
エンティティの設計がデータベースに引き
ずられることなく、そのドメインを正確に
表したものになる
デメリット
SQLを書くのが面倒
検索の結果セットごとにDTOを
作成するため、DTOが増える傾
向がある
Entity設計が、テーブルに引きずら
れ、完全にドメインを表したものにな
らない
学習コストが高い
自動生成されてたSQLの効率が悪くな
るリスクがある
継承やLazyロードによってパフォーマン
スが悪化するリスクがある
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
46
46
02. フレームワーク
参考資料
項目
～EJB 3.0/Spring特徴比較
EJB3.0
Spring
サポート・開発
JCPで規定された標準。仕様は主要なJ2EEサーバー・ベン
ダーなどの関係者が合意。実装は各J2EEサーバー・ベンダー
がサポート。
オープンな(Interface21 Inc)開発、管理。非標準
主目的
エンタープライズ・サービスに必要となる機能をコンテナとして
提供することを目的とし、開発・テスト容易性にも対応
Dependency Injection (DI)をベースとしたアーキテクチャーに
よる、軽量、開発/テスト容易なフレームワーク
DBアクセス
EJBの仕様として、JPAを使用
他のO/Rマッピング・ツールとの統合が容易(JPAもそのうちの
一つ)
トランザクション
JTAトランザクション・マネージャーを使用
JTAトランザクション・マネージャーだけでなく、Spring独自や、
O/Rマッピング・ツールが提供するトランザクション・マネー
ジャーも使用可能
セキュリティ
アノテーションまたはDDによる宣言的セキュリティーをサポート
宣言的セキュリティーをサポートするオープンソースのAcegiフ
レームワークとの統合をサポート
リモートアクセス
リモート・アクセスを主要な機能の一つとし、トランザクションや
セキュリティー属性の伝播も可能
フレームワークとしては、もともとリモート・アクセスは重視してい
ない
テスタビリティー
ほとんどのコンポーネントは、コンテナ外でテスト可能
すべてのコンポーネントをコンテナ外でテスト可能
DI
Java EE の特定の型
(EJBやデータソースなどのリソース)
任意のPOJOをInjection可能
AOP
EJB (Beanまたはメソッド) のみがスコープ
任意のPOJOをスコープとできる
設定の特徴
アノテーションを多用(DD(XML)での設定も可)
XMLの構成ファイルを多用(アノテーションでの設定も可)。
成熟度
まだ、実装は広くは使われていない
広く使われている
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
47
47
02. フレームワーク
参考資料
項目
～JPA/Hibernate/iBATIS特徴比較
EJB 3.0 /JPA
Hibernate
特徴
Hibernateの影響を強く受
けたJCP標準
JavaEE5へ移行を予定して
いる場合。JPAを選択する
機能が豊富にあり、オブジェクトクエリ
言語の「HQL」や、シンプルで扱いやす
いAPIを提供
アノテーション機能がないJDK1.4環境
を利用している場合、Hibernateを選
択する
SQL文をマッピングファイルに記述
メリット
Hibernateに準じる
標準準拠
アノテーションでO/Rマッピン
グを定義する
機能が豊富
Java開発者は、関連を意識しなくて
もよい
SQLレスの開発ができる
永続化オブジェクトクラスのコードから、
O/Rマッピング定義を分離する
SQLの機能が生かせる
パフォーマンスチューニングなどの柔軟
な対応が可能
デメリット
Hibernateに準じる
実装の実績が少ない
関連を多用するとパフォーマンスに影
響
習得に時間が必要
マッピング･ファイルにSQL文を記述す
るため、マッピング･ファイルの管理が
煩雑になる
情報が比較的少ない
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
iBATIS
48
48
02. フレームワーク
参考資料
‰
～DWRの仕組み
DWR 利用イメージ
HTML
HTML/ /JavaScript
JavaScript
function
functioneventHandler(){
eventHandler(){
AjaxService.execute(callback);
AjaxService.execute(callback);
}}
Java
Java
public class AjaxService{
public class AjaxService{
public String execute(){
public String execute(){
return “Hello DWR!”;
return “Hello DWR!”;
}
}
}
}
クラス名.メソッド名
function
functioncallbackr(data){
callbackr(data){
dwr.util.setValue(“result”、data);
dwr.util.setValue(“result”、data);
}
}
メッセージ：Hello DWR!
‰
：処理フロー
DWR全体像
：開発者が作成するもの
クライアント
サーバー
JavaScript
HTML
DHTML
DWR
POJO呼出
コールバック
Creator
XMLHttp
Request
DWRServlet
Converter
リモート
オブジェクト
(POJO)
dwr.xml
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
49
・サーバ側のJavaはPOJO
サーバ側の処理はPOJOとして実装し、すべてDWRのサーブレット (DWRServlet)が処理します。
POJOなのでAPサーバを起動しなくても、単独でテストすることが可能です。
・Java／JavaScript間のデータ変換で多くの型をサポート
サーバのJavaオブジェクトとクライアントのJavaScriptオブジェクトの間でデータ変換を行います。文字
列や単純な型については何も指定しなくても自動的に変換してくれます。また、複雑な型(Array、
Bean、 Collection、 DOM、 Enumオブジェクト)であっても、簡単な記述を追加することでDWRが自動
的に変換することが可能です。
・Struts、JSF、Springなどのフレームワークとの統合
・多くのブラウザに対応
ブラウザによってJavaScriptの振る舞いなどに微妙な違いがありますが、DWRではブラウザの違いを
気にする必要がありません。IEやFireFox、Safari、Opera、Mozilla、Konquerorなど多岐です。
・動的にページを生成するためのユーティリティメソッドを提供
コレクションクラスのオブジェクトをHTMLのテーブルやリストに展開するためのメソッドが用意されて
おり、JavaScriptに詳しくなくても簡単にページをダイナミックに生成することが可能です。
・エラーハンドリング、タイムアウトハンドリング
JavaScriptからサーバ側Javaメソッドを呼び出すときに、エラーハンドラやタイムアウトの指定が簡単に
できます。
・リバースAjax
DWR 1.xまでは、クライアントのJavaScriptからサーバのJavaオブジェクトを非同期に呼び出せました。
DWR 2.0からは、逆に、サーバ側のJavaからクライアントのJavaScriptを非同期に呼び出せるようにな
り、、チャットのような対話型のAjaxアプリケーションを記述しやすくなりました。
＜参考情報＞
WAS Feature Pack for Web 2.0 ワークショップ資料 - 05 Java EEの拡張(Struts/JSFとAjax連携)
http://www.ibm.com/developerworks/jp/websphere/library/was/was61_ejb3fep_ws/index.html
49
02. フレームワーク
参考資料
～Hibernate問題判別(JDBCトレース)
‰ 設定方法
€
管理コンソールより、
データ・ソース -> カスタム・プロパティー
を選択
€
traceLevel、traceFileAppend、
traceFile、traceDirectoryを設定
‰ 問題判別に役立つ主な取得項目
€
JDBCドライバーレベルのレスポンスタイム
[jcc][SystemMonitor:stop]
[jcc][SystemMonitor:stop]core:
core:3.626159ms
3.626159ms| |network:
network:1.7996699999999999ms
1.7996699999999999ms| |server:
server:0.0ms
0.0ms
€
パラメーターマーカーの設定値
Hibernate:
Hibernate:insert
insertinto
intoise.COUNTER
ise.COUNTER(ID)
(ID)values
values(?)
(?)
[jcc][Time:2009-12-01-10:15:53.421][Thread:WebContainer
[jcc][Time:2009-12-01-10:15:53.421][Thread:WebContainer: :3][PreparedStatement@63256325]
3][PreparedStatement@63256325]
setShort
setShort(1,
(1,22)
22)called
called
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
50
JDBCトレースは、管理コンソールより、JDBC -> データ・ソース -> カスタム・プロパティーを選択し、
traceLevel、traceFileAppend、traceFile、traceDirectoryを設定して下さい。traceLevelについては、
下記リンク先をご確認下さい。
・DB2 Information Center - 「サポートされるすべてのデータベース製品に共通の IBM Data Server
Driver for JDBC and SQLJ のプロパティー」
http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.jsp?topic=/com.ibm.db2.luw.apdv.ja
va.doc/doc/r0052038.html
- traceLevel：トレースレベルを設定する。
整数値を加算することで、複数のトレースが取得可能。
例:1+2=3 (CONNECTION_CALL,STATEMENT_CALL)
- traceFileAppend：trueに設定すると、トレースファイルが上書きされない。
- traceFile：トレースファイルを設定する。
-traceDirectory：接続オブジェクト毎にトレースファイルが出力される。
例:_cpds_1 , _cpds_2…。traceFileを設定すると、traceDirectoryは無効になる。
50
02. フレームワーク
参考資料
主要機能
～Ｊａｖａ EEを構成する主なAPI
J2EE 1.3
J2EE 1.4
Java EE 5
Java EE 6
Servlet
2.3
2.4
2.5
3.0
JSP
1.2
2.0
2.1
2.2
JSF
-
-
1.2
2.0
JSTL
-
-
1.2
1.2
JTA
1.0
1.0
1.1
1.1
EJB
2.0
2.1
3.0
3.1
JPA
-
-
1.0
2.0
JMS
1.0
1.1
1.1
1.1
J2EE 1.3
J2EE 1.4
Java EE 5
Java EE 6
XML/Webサービス
Web Service
JAXP
JAX-RPC
-
1.1
1.1
1.3
1.1
1.2
1.2
1.3
-
1.0
1.1
1.1
JAX-WS
-
-
2.0
2.2
JAXB
-
-
2.0
2.2
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
51
51
02. フレームワーク
参考資料
‰
Java SE 関連
€ JDBC4.0
€ JAXP1.3
€ StAX
€ JMX2.0
€ JAF1.1
赤字：Web
赤字：WebProfile候補
Profile候補
青字：Java
青字：JavaEE
EE66新機能
新機能
緑字：Java
EE
緑字：Java EE5でのバージョン
5でのバージョン
*：Prunig対象
*：Prunig対象
～Java EE 6を構成するAPI
‰
Java EE
€ EJB 3.1*(Lite) (←3.0)
€ Servlet 3.0 (←2.5)
€ JSP 2.2 (←2.1)
€ EL 2.2
€ JMS 1.1
€ JTA 1.1
€ JavaMail 1.4
€ Connector 1.6 (←1.5)
€ Web Services 1.3 (←1.2)
€ JAX-RPC 1.1*
€ JAX-WS 2.2 (←2.0)
€ JAX-RS 1.1
€ JAXB 2.2 (←2.0)
€ SAAJ 1.3
€ JAXR 1.0*
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
€
€
€
€
€
€
€
€
€
€
€
€
€
€
Java EE Management 1.1
Java EE Deployment 1.2*
JACC 1.3 (←1.1)
JASPIC 1.0
JSP Debugging 1.0
JSTL 1.2
Web Services Metadata 2.0
JSF 2.0 (←1.2)
Common Annotations 1.1
StAX 1.0
JPA 2.0 (←1.0)
Contexts and Dependency
Injection 1.0
Bean Validation 1.0
JAXM1.0
52
EL (Expression Language)とは、式言語とも呼ばれ、演算結果や値の参照の結果を出力するため
に使用されます。
52
02. フレームワーク
参考資料
～EJB 3.1サンプル
@Singleton
@Singleton
@ConcurrencyManagement(CONTAINER)
@ConcurrencyManagement(CONTAINER)
@Lock(READ)
@Lock(READ)
public
publicclass
classSharedBean
SharedBean{ {
private
privateSharedData
SharedDatashared;
shared;
@Singleton
@Singleton
@ConcurrencyManagement(Bean)
@ConcurrencyManagement(Bean)
@Lock(READ)
@Lock(READ)
public
publicclass
classSharedBean
SharedBean{ {
private
privateSharedData
SharedDatashared;
shared;
@AccessTimeout(1000)
@AccessTimeout(1000)
public
publicint
intgetXYZ()
getXYZ(){ {
return
returnshared.xyz;
shared.xyz;
}}
synchronized
synchronized
public
publicint
intgetXYZ()
getXYZ(){ {
return
returnshared.xyz;
shared.xyz;
}}
@LOCK(WRITE)
@LOCK(WRITE)
public
publicvoid
voidupdate(...)
update(...){ {
////update
updateshared
shareddata
data
}}
synchronized
synchronized
public
publicvoid
voidupdate(...)
update(...){ {
////update
updateshared
shareddata
data
}}
コンテナ管理の並行実行性
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
Bean管理の並行実行性
53
EJB3.1の新機能として、シングルトンSession Beanがあります。シングルトンという名前の通り、アプ
リケーションレベルで一度だけ初期化されます。また、このシングルトンSession BeanのConcurrency
オプションは3種類あります。
・Single threaded (default)：For consistency with all existing bean types
・Container Managed Concurrency：Control access via method-level locking metadata
・Bean Managed Concurrency：All concurrent invocations have access to bean instance
さらに、LOCKのレベルを設定することができます。READ lockは、Beanインスタンスに対して
Concurrentアクセスを許可します。WRITE Lockはデフォルト値となり、シングルスレッドによるBeanア
クセスであることを確認します。そしてLockが解放されるまで、アクセスがブロックされます。
@StartupWeb
@DependsOn
アプリケーション起動処理中に初期化される
シングルトン間の依存関係(起動順)を指定する
53
02. フレームワーク
参考資料
～Servlet 3.0サンプル
@WebServlet(urlPatterns
@WebServlet(urlPatterns=={"/chat"},
{"/chat"},asyncSupported
asyncSupported==true)
true)
public
publicclass
classAjaxCometServlet
AjaxCometServletextends
extendsHttpServlet
HttpServlet{ {
private
privatestatic
staticfinal
finalQueue<AsyncContext>
Queue<AsyncContext>queue
queue== new
newConcurrentLinkedQueue<AsyncContext>();
ConcurrentLinkedQueue<AsyncContext>();
////......
@Override
@Override
protected
protectedvoid
voiddoGet
doGet(HttpServletRequest
(HttpServletRequestreq,
req,HttpServletResponse
HttpServletResponseres)
res) throws
throwsServletException,
ServletException,
IOException
IOException{ { ////......
final
finalAsyncContext
AsyncContextac
ac==req.startAsync();
req.startAsync();
req.setAsyncTimeout(10
req.setAsyncTimeout(10* *60
60* *1000);
1000);
queue.add(ac);
queue.add(ac);
req.addAsyncListener(new
req.addAsyncListener(newAsyncListener(){
AsyncListener(){
public
publicvoid
voidonComplete(AsyncEvent
onComplete(AsyncEventevent)
event)throws
throwsIOException
IOException{ {queue.remove(ac);
queue.remove(ac);} }
public
publicvoid
voidonTimeout(AsyncEvent
onTimeout(AsyncEventevent)
event)throws
throwsIOException
IOException{ {queue.remove(ac);
queue.remove(ac);} }
});
});
////......
}}
非同期処理
2009/12 WAS V7 アプリケーション・デザインWorkshop
アプリケーション・デザインWorkshop
54
54
Fly UP