Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download アナウンスメント・ワークショップ パート WebSphere Application Server V8.0 Java EE 6
Document related concepts
no text concepts found
Transcript
07. Java EE 6 パート1
07.
07. Java EE 6 パート 1
®
WebSphere Application Server V8.0
アナウンスメント・ワークショップ
Java EE 6 パート1
© 2011 IBM Corporation
1
WAS V8.0 アナウンスメント・ワークショップ
WAS V8.0 アナウンスメント・ワークショップ
1
07. Java EE 6 パート1
07.
07. Java EE 6 パート 1
®
Disclaimer
この資料は日本アイ・ビー・エム株式会社ならびに日本アイ・ビー・エム システムズ・エ
ンジニアリング株式会社の正式なレビューを受けておりません。
当資料は、資料内で説明されている製品の仕様を保証するものではありません。
資料の内容には正確を期するよう注意しておりますが、この資料の内容は2011年7月
現在の情報であり、製品の新しいリリース、PTFなどによって動作、仕様が変わる可能
性があるのでご注意下さい。
今後国内で提供されるリリース情報は、対応する発表レターなどでご確認ください。
IBM、IBMロゴ、ibm.com、およびWebSphereは、世界の多くの国で登録された
International Business Machines Corporationの商標です。他の製品名およびサービ
ス名等は、それぞれIBMまたは各社の商標である場合があります。現時点でのIBMの
商標リストについては、http://www.ibm.com/legal/copytrade.shtmlをご覧ください。
JavaおよびすべてのJava関連の商標は Oracleやその関連会社の米国およびその他
の国における商標または登録商標です。
Windows は、Microsoft Corporationの米国およびその他の国における商標です。
Linuxは、Linus Torvaldsの米国およびその他の国における登録商標です。
© 2011 IBM Corporation
2
WAS V8.0 アナウンスメント・ワークショップ
WAS V8.0 アナウンスメント・ワークショップ
2
07. Java EE 6 パート1
07.
07. Java EE 6 パート 1
Agenda
®
Java EE 6 登場の背景
– Java EE 6 登場までの流れ
– Java EE 6 以前の課題
Java EE 6の特長
– Java EE 6の3つのキーワード
Java EE 6の各新機能
– Servlet 3.0
– EJB 3.1
– JSF 2.0
– JPA 2.0
– Bean Validation 1.0
– CDI 1.0
Java SE 6
– WAS ｖ8環境の変更点
まとめ
© 2011 IBM Corporation
3
WAS V8.0 アナウンスメント・ワークショップ
当セッションのアジェンダは以上になります。当セッションではWAS V8がサポートするJava EE 6の
新機能を中心にお話します。
「Java EE 6登場の背景」の章では、JavaEE 6登場までの流れと開発における課題を上げ、「Java
EE 6の特長」の章で、それらの課題に対しどのような改善がなされたかをご紹介します。
「Java EE 6の各新機能」の章では、Servlet 3.0、EJB3.1、JSF2.0、JPA2.0のバージョンアップによる
新機能と、Bean Validation 1.0、CDI 1.0といったJava EE 6から新たに登場した仕様について紹介し
ます。
「Java SE 6」の章では、WAS v8.0から新たに登場したガーベッジ・コレクションなど、WAS v8.0の
Java SE環境について紹介します。
また、JAX-WSやJAX-RSといったWebサービスの機能は、この後の「Java EE 6 パート2」のセッショ
ンでご紹介します。
WAS V8.0 アナウンスメント・ワークショップ
3
07. Java EE 6 パート1
07.
07. Java EE 6 パート 1
®
Java EE 6 登場の背景
© 2011 IBM Corporation
4
WAS V8.0 アナウンスメント・ワークショップ
この章では、JavaEE 6登場までの流れと開発における課題をお話します。
WAS V8.0 アナウンスメント・ワークショップ
4
07. Java EE 6 パート1
07.
07. Java EE 6 パート 1
®
Java EEの歴史
2009年12月リリース
サイズの適正化、最新トレンドの実装により、さらに使い勝手よく開発できる
Java環境の提供
2000 2001 2002 2003 2004 2005
2006
2007
2008
2009
2009.12
1.2
J2EE
1.3
1.4
J2EE
J2EE
エンタープライズシステムを
支えるフレームワーク
4 .0
5 .0
WAS
5 .1
WAS
WAS
Java EE
E5
aE
v
a
J
a
Jav
2010
EE
2011
6
最新トレンドを組み入れた
Java EE へ
軽量化、拡張性、EoD
EoDをテーマに、使いやすいJava EEへ
POJO、DI/AOP、アノテーション
2011.06
6.0 WAS
WAS
6 .1
7.0
WAS
JavaEEサーバー
5
S
WA
WAS
2009.12
sFish
Glas
3.0
8. 0
2011.03
t
omca
he T
Apac
ss
o
B
J
rprise
7.0.6
Ente ation
c
p
Ap li m 6
2012
tfor
PlaCorporation
© 2011 IBM
WAS V8.0 アナウンスメント・ワークショップ
Java EEは、エンタープライズシステムを支えるフレームワークとして2000年に登場しました。その後、
StrutsやSpring Framework、Hibernateといったオープンソース・フレームワークの機能を積極的に
取り入れながら改善を重ねてきました。その最新バージョンは、2009年12月に発表されたJava EE
6になります。Java EE 6では、軽量化や拡張性、EoD(Ease of Development：開発容易性)を中心に、
さらに使い勝手よく開発できる機能を提供しています。WASもJava EEのバージョンアップとともに新
機能を積極的に取り入れながら成長し、今年には、Java EE 6環境を実装したWAS V8.0がリリース
されました。
また、その他のJava EE 6に対応した製品としては、Sun Microsystemsのオープンソース・コミュニ
ティを中心に開発されたGlassFish 3.0があり、Java EE6に対応したアプリケーション・サーバーとし
て、Java EE 6と同時にリリースされました。また、WebコンテナーであるApache Tomcatも、2011年3
月に登場したv7.0.6からJava EE 6に対応されました。JBoss Enterprise Application Platformも来年
リリース予定のv6からJava EE 6に対応するとしています。
WAS V8.0 アナウンスメント・ワークショップ
5
07. Java EE 6 パート1
07.
07. Java EE 6 パート 1
®
Java EE 6仕様
New and Update Technology
Pruning Target
Java EE 6
EJB 3.1
Servlet 3.0
JSP 2.2
EL 2.2
JMS 1.1
JTA 1.1
JavaMail 1.4
Connector 1.6
Web Services 1.3
JAX-RPC 1.1
JAX-RS 1.1
JAXR 1.0
JAX-WS 2.2
JAXB 2.2
Java EE Management 1.1
Java EE Deployment 1.2
JACC 1.3
JASPIC 1.0
JSP Debugging 1.0
JSTL 1.2
Web Services Metadata 2.0
JSF 2.0
Common Annotations 1.1
Java Persistence 2.0
Bean Validation 1.0
Managed Beans 1.0
Interceptors 1.1
DI(JSR-330) 1.0
CDI(JSR-299) 1.0
Java SE
Java IDL
JDBC 4.0
RMI-IIOP
JNDI
JAXP 1.3
StAX 1.0
JAAS
JMX 2.0
JAF 1.1
SAAJ 1.3
Common Annotations 1.1
© 2011 IBM Corporation
6
WAS V8.0 アナウンスメント・ワークショップ
Java EE 6の仕様は上記のようになります。Java EE 6では、ServletやJSFのメジャー・バージョン
アップを中心に、Bean ValidationやCDIなどの新たな仕様も登場し、非常に大規模な仕様になって
います。また、一部の機能はプルーニング対象として、次期Java EE 7で削除される可能性がある
機能となっています。
WAS V8.0 アナウンスメント・ワークショップ
6
07. Java EE 6 パート1
07.
07. Java EE 6 パート 1
®
Java EE 6以前の課題
肥大化するJava EEの仕様
– バージョンアップごとにJava EEの仕様が増加
– コンテナーの動作に影響
– 必要な機能の整理
煩雑化する設定ファイル
– アプリケーションの肥大化に伴う設定ファイルの煩雑化
– フレームワーク固有の情報もJar外部のファイルに記載
増大するクラスファイル数
– Java EEのレイヤー間の結合に必要なクラス（グルーコード）の存在
© 2011 IBM Corporation
7
WAS V8.0 アナウンスメント・ワークショップ
Java EEはバージョンアップにより、多くの機能を取り込んで来ましたが、逆にJava EEの仕様が肥
大化するという課題が生じています。Java EEコンテナーはそれらの仕様が全て実行できるように実
装する必要があるため、Java EEコンテナーの動作は重くなります。そこでJava EE 6では、Java EE
として実装すべき仕様を精査し、必要な機能だけを実装することでJava EEコンテナーを軽量化する
ことが考慮されています。
また、アプリケーションが大きくなるにつれて設定ファイルが煩雑化するという課題もあります。
StrutsではActionServlet、Spring MVCではDispatcherServletというように、フレームワークには固
有のサーブレットがありますが、それらのサーブレットの設定は全てweb.xmlというJarファイルの外
部で指定します。そのため、フレームワークの追加削除の際には、同時に設定ファイルの記載を変
更する必要があります。また、単純にサーブレットの数が増えるにつれ、 web.xmlに記載する記述
の量も多くなるため、設定ファイルへの記述も煩雑になります。
また、アプリケーションの規模が大きくなると、クラスファイルの数も増加しますが、その中には、ビ
ジネス・ロジックとは関係なく、Java EEのレイヤー間の結合のためだけに必要なクラスも存在します。
レイヤーごとに分割して開発することにはメリットもありますが、接続のためだけに必要なクラスが
数多く存在することで、アプリケーションの流れを読み辛くし、アプリケーションを大きくする一因にも
なります。
WAS V8.0 アナウンスメント・ワークショップ
7
07. Java EE 6 パート1
07.
07. Java EE 6 パート 1
®
Java EE 6の特長
© 2011 IBM Corporation
8
WAS V8.0 アナウンスメント・ワークショップ
この章では、Java EE 6の3つの特長を挙げ、開発の課題に対しJava EE 6がどのように改善された
かをお話します。
WAS V8.0 アナウンスメント・ワークショップ
8
07. Java EE 6 パート1
07.
07. Java EE 6 パート 1
®
Java EE 6の3つのキーワード
Rightsizing （軽量化）
Rightsizing
– 「プロファイル」の登場
– 非推奨仕様の策定（プルーニング）
Extensibility （拡張性）
Extensibility
– Webフラグメントによるライブラリーの柔軟な追加
Ease of Development （開発容易性）
Ease of Development
– アノテーションを活用したプログラミング
– 簡略化されたEJBのパッケージング
– Contexts and Dependency Injection（CDI）による
レイヤー間の柔軟な結合
© 2011 IBM Corporation
9
WAS V8.0 アナウンスメント・ワークショップ
Java EE 6では、肥大化する仕様や煩雑化する設定ファイル、増大するクラスファイルといった課題
に対し、Rightsizing（軽量化）、Extensibility（拡張性）、Ease Of Development（開発容易性）の3つを
キーワードに改善がされました。 Rightsizingは、Java EEの一部の機能のみを実装した「プロファイ
ル」、非推奨の機能を策定する「プルーニング」に代表される、軽量化を目指したJava EEの戦略を
指します。 Extensibilityは、「Webフラグメント」に示される、ライブラリーの柔軟な追加を目的とした
機能を指します。 Ease Of Developmentはアノテーションの活用による設定ファイルの記述削減や、
簡略化されたEJBのパッケージング、CDI(Contexts and Dependency Injection)によるレイヤー間の
柔軟な結合などにより、開発をより容易にする機能を指します。
WAS V8.0 アナウンスメント・ワークショップ
9
07. Java EE 6 パート1
07.
07. Java EE 6 パート 1
プロファイルによるJava EEの軽量化
®
Rightsizing
目的に応じ、Java EE 6完全版に対する一部の機能を
「プロファイル」として定義
– 特定のプロファイルを選択してコンテナーを実装することも可能
Java EE
プロファイルの目的
– Java EEコンテナーの起動時間を短縮
– 用途別に利用させ、使いやすさを促進
Profile
Oracle GlassFish Server 3.1 Web Profile (2011.2.28)
– Web Profileだけを実装したアプリケーション・サーバー
– Webプログラムに特化した機能だけを実装することで、
サーバーの起動時間を短縮
主要機能の一部を
コンテナーに実装
© 2011 IBM Corporation
10
WAS V8.0 アナウンスメント・ワークショップ
RightSizingにおける代表的な機能が、Java EE 6から新たに登場した「プロファイル」です。
プロファイルは使用目的に応じてJava EE 6の仕様の一部を定義したものになります。プロファイル
に定義された機能のみをコンテナーに実装することで、コンテナーを軽量化し、起動時間を短縮さ
せる効果があります。また、Java EEを用途別に利用させることで、使いやすさを促進する狙いもあ
ります。
2011年2月に公開されたOracle GlassFish Server 3.1は、Java EEの仕様を全て実装した完全版と
は別に、GlassFish Server 3.1 Web Profileがリリースされています。これはWebアプリケーションに
特化した「Web Profile」のみをサーバーに実装することで、サーバーの起動時間を短縮し、Webアプ
リケーションの開発性向上を図っています。
WAS V8.0 アナウンスメント・ワークショップ
10
07. Java EE 6 パート1
07.
07. Java EE 6 パート 1
®
Java EE ProfileとWeb Profile
Rightsizing
Java EE 6で定義されてるProfile
– Java EE Profile
• Java EEの全仕様を含む
– Web Profile
• Webアプリケーションの実行に必要な仕様だけを含む
ベンダーが独自に定義し、機能を実装しても構わない
Java EE Profile
EJB Lite (EJBの軽量版)
Web Profile
Web Application Technologies
Java Servlet 3.0
JavaServer Faces (JSF) 2.0
JavaServer Pages 2.2
and Expression Language (EL) 1.2
A Standard Tag Library for JavaServer Pages 1.2
Debugging Support for Other Languages 1.0
Enterprise Application Technologies
Contexts and Dependency Injection
for the Java EE Platform 1.0
Dependency Injection for Java
Enterprise JavaBeans 3.1 (EJB Lite)
Java Persistence API 2.0
Common Annotations for the Java Platform 1.1
Java Transaction API (JTA) 1.1
Bean Validation 1.0
その他、定義されている全仕様を実装
© 2011 IBM Corporation
11
WAS V8.0 アナウンスメント・ワークショップ
プロファイルはベンダーが独自に定義し、独自にコンテナーに実装しても構いませんが、Java EE 6
としては2つのプロファイルが定義されています。ひとつはJava EE Profileで、Java EE 6の機能を全
て含むプロファイルです。もうひとつがWeb Profileと呼ばれるもので、Webアプリケーションの実行に
必要な仕様だけを定義したものです。先ほど紹介したGlassFish Server 3.1 Web Profileは、Java EE
6で定義されたWeb Profileの機能を実装したアプリケーション・サーバーになります。
Web ProfileはJava EE 6の仕様の中でも、ServletやJSP、JSFなどWebアプリケーションに特化した
機能のみを抜き出して定義しています。その中にはEJB Liteと呼ばれる機能があります。EJB Lite
もJava EE 6から登場した要素で、EJBの全機能ではなく、EJBの中でもSessionBeanやJTAなど、よ
く使用される機能のみを抜き出して定義したものです。
WAS V8.0 アナウンスメント・ワークショップ
11
07. Java EE 6 パート1
07.
07. Java EE 6 パート 1
®
プルーニング
Rightsizing
非推奨機能の策定
–必要なJava EEの機能を見直し、
互換性のための機能や使用頻度の低い機能をプルーニング対象に
–次期版(Java EE 7)で「削除」「必須」「削除提案のまま」を決定
Java EE 6でプルーニング対象に指定された機能
–EJB2.X Entity Beans
–JAX-RPC
–JAXR
–Java EE Application Development (JSR-88)
© 2011 IBM Corporation
12
WAS V8.0 アナウンスメント・ワークショップ
RightSizingにおけるもうひとつの代表が「プルーニング」です。
プルーニングとは本来、余分な枝や根を切りおろすという意味ですが、Java EE 6では、互換性のた
めだけに残している機能やあまり使用頻度の低い機能をプルーニング対象として定義しています。
プルーニング対象となった機能は、次期のJava EEのリリースの際に「削除」「必須」「削除提案のま
ま」を決定され、削除対象となると、次期バージョンでは削除されます。Java EE 6ではプルーニング
対象となった機能として上記の4つがあります。これらの機能はJava EE 6では使用可能ですが、次
期バージョンでは削除される可能性があるため、バージョンアップの際には考慮が必要です。
WAS V8.0 アナウンスメント・ワークショップ
12
07. Java EE 6 パート1
07.
07. Java EE 6 パート 1
®
Webフラグメント
Extensibility
Servlet 3.0の新機能
– 固有の定義はJarファイルで完結
– フレームワークの追加削除をしやすく
Webフラグメント登場の背景
– アプリケーションにフレームワークを使用するためにJarファイルをlib配下に
– 各フレームワークで必要なサーブレットの定義情報などは、一括してweb.xmlに記述
– 複数のフレームワークを使用することにより、web.xmlのサイズも増加
webApp.war
WEB-INF
web.xml
web.xml
lib
Framework1.jar
Framework2.jar
© 2011 IBM Corporation
13
WAS V8.0 アナウンスメント・ワークショップ
Extensibilityの代表的な機能が「Webフラグメント」です。WebフラグメントはServlet 3.0の新機能のひ
とつで、フレームワーク固有の定義をJarファイル内部で完結させ、外部の設定ファイルを使用しな
いことで、フレームワークの追加や削除を柔軟に行うことを目指した機能です。
Webフラグメントが登場した背景には、設定ファイルの煩雑さ防止があります。アプリケーション開発
では、フレームワークが用いられるケースも多々ありますが、フレームワークを使用するためには、
libディレクトリの配下にJarファイルを配置する必要があります。しかし、StrutsではActionServlet、
Spring MVCではDispatcherServletというように、フレームワークが固有で使用するサーブレットは
決まっており、それらのサーブレットを使用するためには、URLや初期値の設定を一括してweb.xml
というJarファイルの外部で指定しなくてはいけません。そのため、複数のフレームワークを使用す
ることにより、web.xmlにも多くの記載が必要となり、見た目も煩雑になります。さらに、フレームワー
クを削除する際にはweb.xmlから定義の削除も必要となり、フレームワークの追加削除にかかる手
間となります。
WAS V8.0 アナウンスメント・ワークショップ
13
07. Java EE 6 パート1
07.
07. Java EE 6 パート 1
®
Webフラグメントによるモジュールの柔軟性向上
Extensibility
Webフラグメントができること
– jarファイル側でweb-fragment.xmlを用意
– そのフレームワークに必要なweb.xmlへの設定をweb-fragment.xmlに記述
– web.xmlへの記述を削減
– 削除の際もweb.xmlへの変更は不要
webApp.war
WEB-INF
web.xml
lib
Framework1.jar
META-INF/web-fragment.xml
Framework2.jar
META-INF/web-fragment.xml
© 2011 IBM Corporation
14
WAS V8.0 アナウンスメント・ワークショップ
これらを解決する機能がWebフラグメントです。Webフラグメントとは、設定ファイルを各Jarファイル
ごとに用意することで、モジュール全体の設定ファイルへの記述を軽減する機能です。Jarファイル
内部ではMETA-INFの下にweb-fragment.xmlという設定ファイルを用意し、ここに必要な設定を記
述します。モジュール全体で持つweb.xmlは、各Jarファイル内のweb-fragment.xmlを統合し、ひとつ
のweb.xmlとして機能します。この機能を用いることで、 フレームワークの追加削除によるweb.xml
への記述の追加削除は必要なくなるため、柔軟にフレームワークの追加削除が行えるだけでなく、
web.xmlへの記述量も削減できます。
WAS V8.0 アナウンスメント・ワークショップ
14
07. Java EE 6 パート1
07.
07. Java EE 6 パート 1
®
アノテーションを活用したプログラミング
Ease of Development
アノテーションを活用し、設定ファイルの必要性を削減
– 目的はアプリケーションの規模増大による、設定ファイル肥大化の防止
アノテーションベースのサーブレットの例
– Servlet 3.0からはサーブレット・マッピングや、初期化パラメータの指定もアノテー
ションで可能に
webApp.war
webApp.war
WEB-INF
WEB-INF
web.xml
web.xml
classes
Servlet A
Servlet B
サーブレットの定義、マッピング
初期化パラメータなどをweb.xmlに記載
classes
Servlet A
Servlet B
必要な情報は
アノテーションを使って
各コード内に記載
© 2011 IBM Corporation
15
WAS V8.0 アナウンスメント・ワークショップ
Ease of DevelopmentはJava EE 5の特長のひとつでもありましたが、Java EE 6でも継続して目的に
挙げられています。
Java EE 6ではさらにアノテーションを活用し、設定ファイルの必要性を減らすことを目的としていま
す。その一例がサーブレットで使用可能なアノテーションです。既存のサーブレットでは、サーブレッ
トのURLマッピングや、初期化パラメータの指定といったサーブレット固有の設定をweb.xmlに一括
して記載していたため、サーブレットの数が増えると、そのぶんweb.xmlの記載量も多くなりました。
しかし、Java EE 6のServlet 3.0では、サーブレットに必要な設定をアノテーションを用いて各コード
内で設定することが可能になりました。そのため、web.xmlの必要性は削減され、サーブレットの数
が増加してもweb.xmlの記載量を抑えることが可能です。Java EE 6では、webモジュールのweb.xml
はオプション扱いとなっており、必須ではなくなっています。
WAS V8.0 アナウンスメント・ワークショップ
15
07. Java EE 6 パート1
07.
07. Java EE 6 パート 1
®
簡易化されたパッケージング
Ease of Development
EJBのパッケージング
–WarファイルにEJBを含めることが可能
–EJBを含むJarファイルが不要に
–インターフェースも不要
EJB 3.0
EJBSample_web.war
EJBクライアント
WEB-INF/web.xml
WEB-INF/classes/
com/ise/EJBSampleServlet.class
EJB 3.1
EJBSample.war
WEB-INF/classes/
com/ise/EJBSampleServlet.class
com/ise/EJBSampleBean.class
EJBSample_ejb.jar
com/ise/EJBSampleBean.class
com/ise/EJBSample.class
ビジネス・ロジック
インターフェース
© 2011 IBM Corporation
16
WAS V8.0 アナウンスメント・ワークショップ
Java EEが6にバージョンアップしたことにより、対応するEJBも3.0から3.1にバージョンアップしました。
EJB 3.1では、Webモジュール内にEJBを含めることが可能になり、EJBを含むJarファイルは不要に
なりました。また、インターフェイスも不要になったために、Webモジュール内でクライアントとBeanだ
けが存在するという非常にシンプルな構成でEJBを使用することができます。
WAS V8.0 アナウンスメント・ワークショップ
16
07. Java EE 6 パート1
07.
07. Java EE 6 パート 1
®
レイヤー間のシームレスな連携
Ease of Development
Java EE 5が実施したこと
– JSFやJPAを標準化
– 各レイヤーにおいて切り分け
JSF
実行
JSP
Managed
Bean
EJB 3.0
Session
Bean
JPA
JPA
Entity
DB
JSP
出力
facesconfig.xml
Java EE 5の課題
– 結合するための処理が必要
Java EE 5
Java EE 6が実施したこと
– 直接JSFから
EJBやJPAにアクセスし、
結合するためだけの
クラスは不要に
– アノテーションを用いることで、
設定ファイルも最小限に
JSF
実行
出力
XHTML
EJB 3.0
Session
Bean
JPA
JPA
Entity
DB
XHTML
Java EE 6
© 2011 IBM Corporation
17
WAS V8.0 アナウンスメント・ワークショップ
さらにJava EE 6は、レイヤー間のシームレスな連携も考慮されています。Java EE 5ではJSFやJPA
を標準化することで、プレゼンテーションはJSF、ビジネスロジックはEJB、データアクセスはJPAと
いったように、各レイヤー間で仕様を切り分けて開発を行うことが可能になりました。しかし、各コン
ポーネントには固有の作法があったために、連携するための処理は容易ではありませんでした。ま
た、ビジネスロジックとは関係なく、結合のためだけに必要なクラスもあり、アプリケーションを複雑
化する一因でもありました。
Java EE 6ではJBoss Seamを踏襲し、各コンポーネント間のスムーズな連携も行えるようになりまし
た。JSFからは直接EJBやJPAにアクセスすることができ、結合するためだけに必要だったクラスは
不要になりました。さらにアノテーションを用いることで、設定ファイルも必要最小限に抑えることが
可能です。
WAS V8.0 アナウンスメント・ワークショップ
17
07. Java EE 6 パート1
07.
07. Java EE 6 パート 1
®
Java EE 6 各新機能
© 2011 IBM Corporation
18
WAS V8.0 アナウンスメント・ワークショップ
この章では、Servlet 3.0、EJB3.1、JSF2.0、JPA2.0のバージョンアップによる新機能と、Bean
Validation 1.0、CDI 1.0といったJava EE 6から新たに登場した仕様についてお話します。
WAS V8.0 アナウンスメント・ワークショップ
18
07. Java EE 6 パート1
07.
07. Java EE 6 パート 1
Java EE 6 各新機能紹介
®
New
Servlet 3.0
–
–
–
–
新規アノテーションやWebフラグメントを利用したより容易なプログラミング
ログイン・ログアウト
非同期処理
プログラマティックな初期化処理
EJB 3.1
–
–
–
–
–
EJB Liteとパッケージングの簡略化
グローバルJNDI名の標準化
シングルトンセッションBean
カレンダーベースのタイマーサービス
組み込み可能なEJBコンテナー
JSF 2.0
– Facelets
JPA 2.0
– キャッシュの強化
– ペシミスティック・ロックのサポート
Bean Validation 1.0
– アノテーションベースで実行できるバリデーション
CDI(Context and Dependency Injection) 1.0
– 統一化されたDI
– スコープ定義
© 2011 IBM Corporation
19
WAS V8.0 アナウンスメント・ワークショップ
Servletは2.5から3.0へメジャー・バージョンアップし、アノテーションやWebフラグメントを利用したより
容易なプログラミング。Servletによるログイン・ログアウトや非同期処理、Webコンテナーの拡張を
利用した動的な初期化処理などが可能になりました。EJB 3.1は3.0からバージョンアップし、EJB
Liteやパッケージングの簡略化、シングルトンセッションBean、カレンダーベースで利用できるタイ
マーサービス、EJBコンテナーを組み込んだ単体テストに対応した点などが新機能になります。JSF
は1.2から2.0へメジャー・バージョンアップし、XHTMLベースのFacelets、 Ajaxのサポートなどが新機
能となります。JPAも1.0から2.0にメジャー・バージョンアップし、強化されたキャッシュ機能やペシミ
スティック・ロックのサポートを始め、JPQLや各APIも改善がなされました。
Bean ValidationとCDIはJava EE 6から新たに登場した機能です。Bean Validationはアノテーション
ベースで行うバリデーションであり、フィールドやBeanのバリデーションをコード上でより簡単に行う
ことが可能になりました。CDIはContext and Dependency Injectionの略で、DIの仕様を統一化し、ス
コープ定義をアノテーションベースで簡単に行える機能です。
WAS V8.0 アナウンスメント・ワークショップ
19
07. Java EE 6 パート1
07.
07. Java EE 6 パート 1
Servlet 3.0 ～新機能
®
Ease of Development
–アノテーションやWebフラグメントの登場
セキュリティー
–Servletによるログインログアウトの実現
非同期処理
–Servletによる非同期処理の実現
拡張性の向上（Pluggability）
–プログラムによるWebコンテナーの拡張
–サーブレットやフィルターの動的な追加
© 2011 IBM Corporation
20
WAS V8.0 アナウンスメント・ワークショップ
Servlet 3.0の新機能は以上のようになります。さらなるEase of Developmentとして、構成のための
アノテーションが大きく追加され、拡張性を高めるためにWebフラグメントが登場しました。さらに、
Servletによるログイン・ログアウトや非同期処理も実現可能になり、Webコンテナーを拡張した初期
化処理や、サーブレットやフィルターを動的に追加することも可能になりました。
WAS V8.0 アナウンスメント・ワークショップ
20
07. Java EE 6 パート1
07.
07. Java EE 6 パート 1
Servlet 3.0 ～アノテーションと拡張性向上
®
アノテーションベースのプログラミングを推進
– web.xmlをオプション化
アノテーション
用途
@WebServlet
Servletの定義（name、urlpattern）
@WebFilter
フィルターの定義
@WebListener
リスナーの定義
@WebInitParam
初期パラメーターの定義
– アノテーションの設定はweb.xmlで上書き
優れた拡張性
Framework1.jar
– web-fragment.xmlによるweb.xmlの分割
META-INF/web-fragment.xml
•Jarファイル内でのweb.xmlの設定が可能
– META-INF/resourcesディレクトリ
•静的コンテンツを保管
•コンテキストルートでアクセス可能
Framework1.jar
META-INF/resources/sample.html
http://www.aaa.com/context_root/sample.html
© 2011 IBM Corporation
21
WAS V8.0 アナウンスメント・ワークショップ
Servlet 3.0では、Java EE 5同様にアノテーションベースのプログラミングを推進すべく、さらに多くの
アノテーションが追加されました。今まではweb.xmlのような外部の設定ファイルで指定していた
サーブレットの定義やフィルター、リスナー、初期パラメーターなどの定義もアノテーションで記載が
可能になりました。これにより、 web.xmlはオプション扱いとなり、サーブレットの追加による設定ファ
イルの煩雑化を防止しています。今まで同様にweb.xmlも使用することも可能ですが、アノテーショ
ンの設定はweb.xmlで上書きされてしまう点は注意が必要です。
また、拡張性を高めるためにweb-fragment.xmlによるweb.xmlの分割が可能になりました。これによ
り、各Jarファイル内でのweb.xmlの設定が可能となり、外部の設定ファイルの影響を受けずにモ
ジュールの追加削除が可能になります。さらに、WEB-INF/libに配置されたJarファイル内でMETAINFのresourcesディレクトリに保管された静的コンテンツを、コンテキストルートでアクセスすることも
可能になりました。
WAS V8.0 アナウンスメント・ワークショップ
21
07. Java EE 6 パート1
07.
07. Java EE 6 パート 1
Servlet 3.0 ～ログイン・ログアウト
®
新しい認証方式
– フォーム認証の実現
– <form action=“j_security_check” method=“post”>の機能をServletで実現
認証のための新しいメソッド
– HttpServletRequest#authenticate(HttpServletResponse response)
– HttpServletRequest#login(String username, String password)
– HttpServletRequest#logout()
アノテーションも追加
– @ServletSecurity
– 「R1」ロールをもったユーザーからGETアクセスを制限
@ServletSecurity (value=@HttpConstraint(rolesAllowed="R1"),
httpMethodConstraints=@HttpMethodConstraint("GET"))
public class SecurityServlet extends HttpServlet{
…（略）
}
© 2011 IBM Corporation
22
WAS V8.0 アナウンスメント・ワークショップ
Servlet 3.0では、formタグで行っていたフォーム認証をサーブレットで行うことも可能になりました。
認証を実現するためのメソッドとして、HttpServletRequestにauthenticate、login、logoutというメソッ
ドが追加されました。また@ServletSecurityというアノテーションも追加され、ロールベースのアクセ
ス制御をアノテーションで行うことも可能になりました。
WAS V8.0 アナウンスメント・ワークショップ
22
07. Java EE 6 パート1
07.
07. Java EE 6 パート 1
Servlet 3.0 ～非同期処理
®
非同期リクエスト処理用のモデルを提供
Servletの実行スレッドを早期解放
非同期処理を行うスレッドはリクエストの情報を保有し、レスポンスを返す
Servlet
Servlet
doGet()
doGet()
時間の
かかる
処理
Servlet 3.0
別スレッド
startAsync(req,resp)
+ start()
時間の
かかる
処理
response
response
© 2011 IBM Corporation
23
WAS V8.0 アナウンスメント・ワークショップ
Servlet 3.0では非同期リクエストを処理するための仕組みを提供しています。同期処理では、時間
のかかる処理を行っている間、サーブレットの実行スレッドは常に占有された状態となり、他のリク
エストを処理することができません。Servlet 3.0の非同期処理では、サーブレットがリクエストを受け
ると、別スレッドに処理を移管させ、リクエストを受けたサーブレットはそこで処理を終了します。そ
の後、時間のかかる処理を別スレッドで実行させ、レスポンスは別スレッドから返します。そうするこ
とで、サーブレットの実行スレッドは早期に開放され、他のリクエスト処理のために待機させること
が可能です。
WAS V8.0 アナウンスメント・ワークショップ
23
07. Java EE 6 パート1
07.
07. Java EE 6 パート 1
Servlet 3.0 ～非同期処理の例
®
@WebServletの引数 asyncSupported=true に設定
protected void doGet
(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException {
public static class Async implements Runnable {
AsyncContext ctx;
public Async(AsyncContext ctx) {
this.ctx = ctx;
}
System.out.println("サーブレット開始");
@Override
//③runメソッドの実行
public void run() {
//①AsyncContext取得
AsyncContext actx =
request.startAsync(request,response);
// ④時間のかかる処理…
//②非同期処理実行開始
actx.start(new Async(actx));
//レスポンスの出力
java.io.PrintWriter writer =
ctx.getResponse().getWriter()
writer.println(“<html>処理終了</html>");
writer.close();
System.out.println("サーブレット終了");
}
//⑤同期化処理の終了
ctx.complete();
}
}
24
© 2011 IBM Corporation
WAS V8.0 アナウンスメント・ワークショップ
非同期処理を行うサーブレットの例です。非同期処理を行うサーブレットは@WebServletの引数とし
てasyncSupportedをtrueに設定する必要があります。サーブレットでは、まずHttpServletRequestの
startAsyncメソッドを実行し、AsyncContextを取得します。取得したAsyncContextのstartメソッドを
実行することで、非同期処理が実行され、サーブレットは処理を終了します。startメソッドは非同期
処理を行うクラスを引数にとります。非同期処理を行うクラスはRunnableをインプリメントし、runメ
ソッドを実装します。 startメソッドにより、 非同期処理を行うクラスのrunメソッドが実行され、時間の
かかる処理をここで実行します。その後にブラウザにレスポンスとして返す内容を記載し、処理の
最後にAsyncContextのcompleteメソッドにより同期化処理を終了させます。
WAS V8.0 アナウンスメント・ワークショップ
24
07. Java EE 6 パート1
07.
07. Java EE 6 パート 1
Servlet 3.0 ～プログラマティックな初期化処理
®
ServletContainerInitializer
– ServletContainerInitializerインターフェイスをインプリメントし、onStartupメソッドを実装
– コンテナーがモジュールをロードした際、onStartupメソッドが実行され、
初期化処理が実行可能
– サーブレットの登録やマッピングなどをonStartup内で動的に登録することも可能
public class ServletContainerInitializerImpl implements ServletContainerInitializer {
@Override
public void onStartup(Set<Class<?>> arg0, ServletContext context) throws ServletException {
System.out.println("-------On Start Up !!--------");
ServletRegistration reg = context.addServlet("initServlet", "test.init.InitServlet");
reg.addMapping("/initServlet");
}
｝
– META-INF/servicesにjavax.servlet.ServletContainerInitializerという名のファイルを作成
• 中身は実装クラスを記載
© 2011 IBM Corporation
25
WAS V8.0 アナウンスメント・ワークショップ
Servlet 3.0からServletContainerInitializerというインターフェイスが追加されました。このインターフェ
イスをインプリメントしたクラスは、onStartupメソッドを実装します。onStartupメソッドはコンテナーが
モジュールをロードした際に実行されますので、サーブレットの初期化処理を行うことが可能です。
また、Servlet 3.0ではサーブレットの登録やマッピングなどを動的に行うことができますので、
onStartupメソッド内でサーブレットやリスナーの登録を行うことも可能です。
この機能を用いる際には、WebモジュールのMETA-INF/servicesディレクトリに
javax.servlet.ServletContainerInitializerというファイルを作成しておく必要があります。このファイル
にはServletContainerInitializerをインプリメントしたクラスを記載しておくことで、コンテナーの起動時
にonStartupメソッドが実行されます。
WAS V8.0 アナウンスメント・ワークショップ
25
07. Java EE 6 パート1
07.
07. Java EE 6 パート 1
EJB 3.1 ～新機能
®
シンプルなプログラミングモデル
–EJB Liteの登場
–シングルトンセッションBeanの登場
–より利用しやすいタイマーサービス
–グローバルJNDI名の統一
単体テストの容易な実現
–JavaSE環境にEJBコンテナーを組み込んで単体テストを実行
© 2011 IBM Corporation
26
WAS V8.0 アナウンスメント・ワークショップ
EJB3.1の新機能は以上のようになります。EJB3.1では、よりシンプルなプログラミングモデルを実現
するために、さまざまな機能が追加されました。Webプロファイルで採用されたEJB Liteをはじめ、
Webモジュール内で使用可能なパッケージング。シングルトンセッションBean。より開発者にとって
わかりやすいタイマーサービス、グローバルJNDI名の採用などがその代表です。また、単体テスト
を容易に実現するために、Java SE環境にEJBコンテナーを組み込んで単体テストを実行することも
可能になりました。
WAS V8.0 アナウンスメント・ワークショップ
26
07. Java EE 6 パート1
07.
07. Java EE 6 パート 1
EJB 3.1 ～EJB概要
®
EJB(Enterprise Java Bean)の目的
EJBの開発を困難にしている理由
– ビジネス・ロジックの分離
– トランザクションの管理と
分散オブジェクト技術の統合
– 本質的なビジネス・ロジックとは関係ない
作成物、実装コードが多い
– 継承、実装の作法が複雑
EJB（EJBコンテナー）ができること
–
–
–
–
–
トランザクション管理
アクセス制御
タイマーサービス
リモート呼び出し（分散オブジェクト処理）
データの永続化
インターフェイス
@Remoteアノテーション
ビジネス・ロジック
@Statefulアノテーション
implements EJBSample)
EJB 2.1
EJB 3.0
EJBSample_web.war
WEB-INF/web.xml
WEB-INF/classes/
com/ise/EJBSampleServlet.class
EJBSample_web.war
ビジネス・ロジック
（implements SessionBean)
EJBSample_ejb.jar
WEB-INF/web.xml
WEB-INF/classes/
com/ise/EJBSampleServlet.class
EJB 3.0
com/ise/EJBSampleBean.class
com/ise/EJBSample.class
com/ise/EJBHome.class
EJBSample_ejb.jar
インターフェース
（extends EJBObject)
Homeインターフェース
（extends EJBHome)
27
com/ise/EJBSampleBean.class
com/ise/EJBSample.class
© 2011 IBM Corporation
WAS V8.0 アナウンスメント・ワークショップ
EJBの概要とEJB3.0までの軌跡について説明します。
EJBは、アプリケーションにおけるビジネス・ロジックの分離、トランザクションの管理と分散オブジェ
クト技術の統合を目的にJ2EE 1.2からJ2EEの仕様となりました。EJBは、トランザクション管理をは
じめ、アクセス制御、タイマーサービス、リモート呼び出し、データの永続化など、エンタープライズ・
アプリケーションにとって多くの役立つ機能を持っていますが、その反面、開発が困難な面もありま
した。その理由として、ビジネス・ロジックとは関係のない作成物や実装コードが多いこと。また継承
や実装の作法が複雑で理解しづらいことなどが挙げられます。
EJB2.1とEJB3.0のパッケージの違いを上図に示します。EJB2.1では、ビジネス・ロジックを担うBean
以外にもリモート・インターフェイスやHomeインターフェイスが必要でした。また、Homeインターフェ
イスはEJBHomeクラスを継承し、リモート・インターフェイスはEJBObjectクラスを継承し、さらにビジ
ネス・ロジックはSessionBeanを実装し…と、継承や実装の作法が多く、 各クラスの関係がわかり辛
いという問題がありました。そういった問題を改善するために、EJB3.0からは、よりシンプルな構成
でのパッケージングが可能になりました。ビジネス・ロジックを実装しているクラスの作成と、その公
開メソッドをインターフェースとして公開し、EJBモジュールとしてパッケージするという、クラス間の
関係もわかりやすくなり、EJB固有のクラスやインターフェースを継承する必要なくなりました。
WAS V8.0 アナウンスメント・ワークショップ
27
07. Java EE 6 パート1
07.
07. Java EE 6 パート 1
EJB 3.1 ～EJB Liteとパッケージの簡略化
EJB Lite
– Web Profileで利用されている
– 簡略化されたEJBの機能のみを定義
パッケージの簡略化
– Webモジュールのみ。Jarは不要
– インターフェイスも不要
– JavaEE 5同様のパッケージングも可能
®
EJB完全版
EJB Lite
Message Driven Beans
EJB Component Web
Service Endpoints
RMI-IIOP Interoperability
2.x/3.x Remote View
2.x Local View
Timer Service
CMP / BMP
Local Session Beans
Annotations / ejb-jar.xml
CMT / BMT
Declarative Security
Interceptors
JPA 2.0
JTA 1.1
EJB 3.0
EJB 3.1
EJBSample_web.war
WEB-INF/web.xml
WEB-INF/classes/
com/ise/EJBSampleServlet.class
EJBSample_ejb.jar
EJBSample.war
EJB 3.1
WEB-INF/classes/
com/ise/EJBSampleServlet.class
com/ise/EJBSampleBean.class
com/ise/EJBSampleBean.class
com/ise/EJBSample.class
© 2011 IBM Corporation
28
WAS V8.0 アナウンスメント・ワークショップ
EJB3.1では、さらに使いやすいEJBを目指し、さまざまな新機能が追加されました。その代表的な
機能のひとつがEJB Liteです。EJB LiteはWebプロファイルで利用されるもので、EJBの機能のうち、
主に使用される機能のみを抜き出して定義したものになります。具体的には上図にあるように、
Local Session BeanやJPA、JTAなどの機能が含まれます。Webプロファイルのみを実装したコンテ
ナーは、EJBにおいても使用頻度の高い機能のみを実装しているため、Java EEの全機能を実装し
たコンテナーよりも起動が早く、開発をより快適な環境で行うことができます。
また、EJBのパッケージもさらに簡略化されました。EJB3.0では、EJBのビジネス・ロジックを含むク
ラスとそのインターフェイスが必要でした。また、それらはEJBモジュールとして別途パッケージング
が必要でした。しかし、EJB3.1からはEJBクライアントとEJBのビジネス・ロジックをWebモジュール内
で同梱させることができ、EJBモジュールを別途作成する必要も、EJBのインターフェイスも必要なく
なりました。もちろんJava EE 6環境でもJava EE 5同様のパッケージングも可能ですので、EJB3.0も
実行させることが可能です。
WAS V8.0 アナウンスメント・ワークショップ
28
07. Java EE 6 パート1
07.
07. Java EE 6 パート 1
EJB 3.1 ～シングルトンセッションBean、タイマーサービス
®
シングルトンセッションBean
– アプリケーションで唯一のインスタンスを保証
– デフォルトではコンテナーがアクセス制御を実行
• @ConcurencyManagement(BEAN)を指定し、開発者がアクセス制御をコードで行うことも可能
• @Lock(READ) 複数アクセスの読み込み許可
• @Lock(WRITE) 書き込みは単一アクセス
タイマーサービス
– カレンダー表記での時間指定
// 月～金の正午
ScheduleExpression expr = new ScheduleExpression().dayOfWeek(“Mon-Fri”).hour(12);
timerSvc.createTimer(expr, null);
– @Scheduleアノテーションでの指定
@Schedule(dayOfWeek=”Mon”)
@Schedule(minute=”15”, hour=”3”, dayOfWeek=”Mon-Fri”)
// 毎月曜日深夜0:00
// 月～金の午前3:15
© 2011 IBM Corporation
29
WAS V8.0 アナウンスメント・ワークショップ
EJB3.1からシングルトンセッションBeanが新機能として追加されました。シングルトンセッションBean
はアプリケーションで唯一のインスタンスであることを保証するセッションBeanで、デフォルトでは
EJBコンテナーがBeanの管理を行いますが、 @ConcurencyManagement(BEAN)を指定し、開発者
がアクセス制御をコードで行うことも可能です。コンテナーがアクセスを制御する場合、複数アクセ
スの読み込みを許可するか、単一アクセスの書き込みのみ許可するか、といった制御を@Lockアノ
テーションを用いて指定します。
タイマーサービスは以前のEJBでもありましたが、EJB3.1では、カレンダー表記で時間の指定がより
わかりやすくなりました。例えば平日の正午にタイマーをセットする場合、 dayOfWeek(“MonFri”).hour(12)と指定します。また、@Scheduleアノテーションを用いたタイマー定義も可能になりまし
た。
WAS V8.0 アナウンスメント・ワークショップ
29
07. Java EE 6 パート1
07.
07. Java EE 6 パート 1
EJB 3.1 ～グローバルJNDI名の標準化
®
グローバルJNDI名の統一
– グローバル・レベル
java:global/[app-name]/module-name/ejb-name
– アプリケーション・レベル
java:app/module-name/ejb-name
– モジュール・レベル
java:module/ejb-name
@Stateless
java:global/application/hello/HelloBean
public class HelloBean implements Hello {
public String sayHello(String message) {
return “Hello ! ”+ message ;
java:app/hello/HelloBean
}
}
java:module/HelloBean
© 2011 IBM Corporation
30
WAS V8.0 アナウンスメント・ワークショップ
EJB3.1では、EJBにアクセスする際に使用するJNDI名についても統一が図られました。具体的には、
グローバルにEJBを呼び出す際にはjava:global/[app-name]/module-name/ejb-name。アプリケー
ション内で呼び出す際にはjava:app/module-name/ejb-name。モジュール内で呼び出す際には
java:module/ejb-nameと定められました。グローバルJNDI名はアプリケーション・サーバーを提供す
るベンダー独自に設定していましたが、統一されたグローバルJNDI名を使用することにより、EJBコ
ンテナーを他製品へ移行した際でも、JNDI名の変更は必要なくなります。
WAS V8.0 アナウンスメント・ワークショップ
30
07. Java EE 6 パート1
07.
07. Java EE 6 パート 1
EJB 3.1 ～組み込み可能なEJBコンテナー
®
EJBはEJBコンテナーが必要なため、単体テストは困難
EJB 3.1からはJavaSEにEJBコンテナーを組み込んで使用可能
– JUnitなどを用いて単体テストが可能
– 開発向けの機能
HashMapとしてEJBコンテナーの情報を入力
public void testSayHello() {
Map map = new HashMap();
glassfishの場合
p.put(“org.glassfish.ejb.embedded.glassfish.instance.root”,
“/Applications/GlassFish/glassfishv3-webprofile/
glassfish/domain/domain1”);
map.put(“EJBContainer.PROVIDER”,
”com.ibm.websphere.ejbcontainerEmbeddableContainerProvider”);
EJBContainer container = EJBContainer.createEJBContainer(map);
try｛
Hello hello = (Hello)container.getContext().lookup(“java:global/hello/HelloBean”);
System.out.println(hello.sayHello());
catch(Exception e){
EJBContainerクラスのContextよりEJBをlookup
e.printStackTrace();
｝
｝
© 2011 IBM Corporation
31
WAS V8.0 アナウンスメント・ワークショップ
EJBを動作させるためにはEJBコンテナーが必要です。そのためEJBは作成しても単体テストが困
難という課題がありました。
EJB3.1では、JavaSE環境にEJBコンテナーを組み込んで使用することが可能になりました。上に
EJBにアクセスして結果を見るためのテストコードを示します。まずHashMapクラスを作成し、属性に
EJBContainer.PROVIDER、値にcom.ibm.websphere.ejbcontainerEmbeddableContainerProviderを
putします。入力する値はWASに固有の内容ですので、他のEJBコンテナーでは別途違ったEJBコ
ンテナーの情報をputします。さらにEJB3.1から登場したjavax.ejb.embeddable.EJBContainerの
createEJBContainerメソッドにその情報を渡し、EJBContainerクラスを作成します。作成された
EJBContainerクラスからgetContextメソッド、さらにlookupメソッドを用いてEJBをルックアップするこ
とで、EJBオブジェクトを作成することができます。この機能は開発向けの機能とされていますが、
JUnitなどのテストツールを用いてEJBの単体テストを行えるため、使い勝手の良い機能と言えるで
しょう。
WAS V8.0 アナウンスメント・ワークショップ
31
07. Java EE 6 パート1
07.
07. Java EE 6 パート 1
JSF 2.0 ～新機能
®
Facelets
–JSP+JSFタグからXHTML+JSF属性に変更
Ajaxのサポート
–<f:ajax>タグによりJavaScriptを動的に生成
アノテーション対応
–マネージドBeanがPOJO＋アノテーションだけで作成可能
–JSFの設定ファイルfaces-config.xmlのオプション化
Bean Validation対応
© 2011 IBM Corporation
32
WAS V8.0 アナウンスメント・ワークショップ
JSF 2.0の新機能は以上のようになります。Java EE 6により、JSFは1.2から2.0へとバージョンアップ
しましたが、大きな新機能としては、JSPからJSFのタグを利用して画面表示させていた部分を
XHTMLベースで行う「Facelets」の登場が挙げられます。その他、 AjaxのサポートによりJavaScript
を動的に生成できるようになった点や、アノテーションによりJSFの設定ファイルがオプション化され
た点、Bean Validationへの対応などが挙げられます。
WAS V8.0 アナウンスメント・ワークショップ
32
07. Java EE 6 パート1
07.
07. Java EE 6 パート 1
JSF 2.0 ～JSF概要
®
Java EE標準のUIコンポーネント・フレームワーク
– UIコンポーネントを視覚的に扱い、Webアプリケーションの画面開発が容易に可能
JSFの構成要素
– FacesServlet
• リクエスト処理を受け付けるサーブレット
– Lifecycleクラス
• FacesServletクラスから呼ばれ、処理のコントロールを実施
– マネージドBean
• Webブラウザからの入出力値を保持し、処理を実行するBeanクラス
– JSFタグ
• JSFが提供するタグライブラリ
– UIコンポーネント
• テキストフィールド、サブミットボタンなど、ユーザーとの入出力インターフェイスを構成する部品群
JSF Application
HTTPリクエスト
実行
FacesServlet
Lifecycle class
Managed Bean
生成
出力
HTTPレスポンス
JSP
参照・更新
JSF Tag
UI Component
参照
© 2011 IBM Corporation
33
WAS V8.0 アナウンスメント・ワークショップ
JSFの概要について説明します。
JSF(Java Server Faces)はJava EE 5からJava EEの仕様となったUIコンポーネント・フレームワーク
です。UIコンポーネントを視覚的に扱うことで、Webアプリケーションの画面開発を容易に行うことが
可能です。JSFの構成要素には、FacesServlet、Lifecycleクラス、マネージドBean、JSFタグ、UIコン
ポーネントの5つがあります。開発者が作成するのは、各JSPページとマネージドBeanです。
HTTPのリクエストはまずFacesServletが処理を受け付け、LifeCycleクラスを呼び出します。
LifeCycleクラスはライフサイクルを管理し処理をコントロールするクラスで、マネージドBeanに処理
を依頼したり、画面出力を担当するJSPページにフォワードしたりといった作業を行います。マネー
ジドBeanはブラウザからの入力値や出力値を保持し、それらに対して処理を行うクラスです。その
際、入力値の検証や値の参照はUIコンポーネントツリーを介して行います。UIコンポーネントは、テ
キストフィールドやサブミットボタンといった、ユーザーとの入出力インターフェイスを構成する部品
群で、入力画面・出力画面について各UIコンポーネントツリーが生成され、マネージドBeanやJSPが
ツリー内の値を参照することで処理を行います。出力を担当するJSPページにはJSFが提供するタ
グライブラリであるJSFタグが記載されており、タグに従ってHTMLコードを出力します。
WAS V8.0 アナウンスメント・ワークショップ
33
07. Java EE 6 パート1
07.
07. Java EE 6 パート 1
JSF 2.0 ～Facelets
®
JSPによる表示の課題を解決
– コードの編集、保存、再読み込みを行うたびに、JSPコンパイラがServletを生成し実
行するのはオーバーヘッドになる
FaceletsはXHTMLを使用
– XMLをSAXにより解析
テンプレート機能
– 画面上のヘッダやフッタ、左ペインなど、共通部分をテンプレートとして記載
– 開発効率やメンテナンス性を向上
© 2011 IBM Corporation
34
WAS V8.0 アナウンスメント・ワークショップ
JSF2.0の新機能のひとつにFaceletsがあります。JSF1.2ではJSPを用いて画面表示を行っていまし
たが、コードの編集、保存、再読み込みの度にJSPコンパイラがServletを生成しServletを実行する
ことで画面表示を行うため、オーバーヘッドが高いという課題がありました。そこでFaceletsでは
XHTMLを使用し、XMLをSAXにより解析を行うことで出力のオーバーヘッドを軽減しています。また、
Faceletsは画面上の共通部分をテンプレートとして扱うこともできるため、開発効率やメンテナンス
性を向上できます。
WAS V8.0 アナウンスメント・ワークショップ
34
07. Java EE 6 パート1
07.
07. Java EE 6 パート 1
JPA 2.0 ～新機能
®
O/Rマッピング
– Embeddablesの多段構成のサポート
– JPQLの更新
ランタイムAPIの更新
– EntityManagerFactory API, EntityManager API, Query API, Typed Result API
キャッシュの強化
– JPAの設定ファイルで設定可能
– エンティティやクエリごとに詳細に設定することも可能
ペシミスティック・ロックのサポート
– JPA2.0として正式にサポート
Bean Validation対応
※Embeddabｌes エンティティ・クラスに組み込んで処理を委譲できるクラス
複数のエンティティに共通のデータを抽出し、Embeddableとして各エンティティに
組み込んで使用する
© 2011 IBM Corporation
35
WAS V8.0 アナウンスメント・ワークショップ
JPA 2.0の新機能は以上のようになります。 Java EE 6により、JPAは1.0から2.0へとバージョンアッ
プしました。新機能としてはEmbeddablesの多段構成やJPQLの更新。各ランタイムAPIの更新、
キャッシュの強化、ペシミスティック・ロックのサポート、Bean Validationへの対応などが挙げられま
す。このセッションでは、新機能としてキャッシュの強化とペシミスティック・ロックのサポートについ
て紹介します。
WAS V8.0 アナウンスメント・ワークショップ
35
07. Java EE 6 パート1
07.
07. Java EE 6 パート 1
JPA 2.0 ～JPA概要
®
Java EE標準のO/Rマッピング技術
– ベースはPOJO
– javax.persistenceパッケージで定義されたAPI
– JPQL(Java Persistence Query Language)によるDB操作
RDBに格納されているデータを
オブジェクトとして直感的に扱う
1レコード＝1つのJavaオブジェクト
JPAの構成要素
– エンティティ・クラス
• データベースの1テーブルに相当し、永続化可能なJavaクラス
– エンティティ・マネージャー
• エンティティを操作するためにJPAが提供するインターフェース。レコードの取得、更新、削除を実行
– パーシスタンス・コンテキスト
• エンティティ・インスタンスの集合。DBと同期を取ることが保証された、レコードのキャッシュ
© 2011 IBM Corporation
36
WAS V8.0 アナウンスメント・ワークショップ
JPAの概要について説明します。
JPA(Java Persistance API)はJava EE 5からJava EEの仕様となったO/Rマッピング技術です。O/R
マッピングとは、リレーショナルモデルのデータとオブジェクトモデルのデータのマッピングを行う技
術で、O/Rマッピングによりリレーショナル・データベース上のデータをJavaオブジェクトとして直感
的に扱うことが可能になります。基本的にはひとつのレコードに対しひとつのJavaオブジェクトが対
応します。JPAはPOJOをベースとしており、javax.persistenceで定義されたAPIを用いて開発を行い
ます。DB操作にはJPQL(Java Persistence Query Language)というSQLライクな言語を使用します。
JPAの構成要素にはエンティティ・クラス、エンティティ・マネージャー、パーシスタンス・コンテキスト
の3つがあります。開発者が作成するのは、JPAを使用するアプリケーションと各データベースに対
するエンティティ・クラスです。
エンティティ・クラスはデータベースの1テーブルの相当し、データの永続化が可能なJavaクラスです。
JPAを使用するアプリケーションは、まずエンティティ・マネージャーを生成します。エンティティ・マ
ネージャーはエンティティを操作するためのインターフェイスであり、エンティティ・クラスに対し1レ
コードの取得やデータの更新、削除などを行います。エンティティ・マネージャーを通じて検索・挿
入・削除・更新を行うと、JPAエンジンがデータベースに対し指定された操作を行います。エンティ
ティ・マネージャーによって取得されたエンティティ・オブジェクトの集合をパーシスタンス・コンテキス
トと呼びます。パーシスタンス・コンテキストはデータベースのレコードの内容をキャッシュしたもの
ですが、データが更新された場合もデータベースと同期を取ることが保証されたキャッシュになりま
す。
WAS V8.0 アナウンスメント・ワークショップ
36
07. Java EE 6 パート1
07.
07. Java EE 6 パート 1
JPA 2.0 ～二次キャッシュ
®
一次キャッシュ
– 単一のパーシスタンス・コンテキストのエンティティに対するキャッシュ
– エンティティ・マネージャーが管理
二次キャッシュ
– 複数のパーシスタンス・コンテキストのエンティティのキャッシュを共有
– JPAの設定ファイルpersistence.xmlの<shared-cache-mode>で設定
設定
動作
ALL
全てキャッシュ（デフォルト）
NONE
キャッシュ無効
ENABLE_SELECTIVE
@Cacheable(true)の指定があるもののみキャッシュ
DISABLE_SELECTIVE
@Cacheable(false)の指定があるもののみキャッシュしない
– クエリレベルでの設定例
TypedQuery<Guest> query = em.createQuery(“SELECT g FROM Guest g“);
query.setProperty(“javax.persistence.cache.retrieveMode”,CacheRetrieveMode.BYPASSS);
query.setProperty(“javax.persistence.cache.storeMode”,CacheStoreMode.REFRESH);
retriveMode データ検索
BYPASS(DBから取得) / USE(キャッシュから取得)
storeMode データ保存
BYPASS(DBに保存) / REFRESH(既存キャッシュを置き換え) / USE(キャッシュを更新しDBに反映）
© 2011 IBM Corporation
37
WAS V8.0 アナウンスメント・ワークショップ
JPA 2.0では、パーシスタンス・コンテキスト内のエンティティに対するキャッシュが強化されています。
JPA 1.0では、ひとつのパーシスタンス・コンテキストのエンティティに対するキャッシュのみがサ
ポートされていましたが、JPA 2.0では、複数のパーシスタンス・コンテキストについてエンティティの
キャッシュを共有することが可能になりました。キャッシュの設定はJPAの設定ファイル
persistence.xmlの<shared-cache-mode>タグで以上のように設定できます。デフォルトでは全て
キャッシュするように設定されています。また、キャッシュの設定はエンティティやクエリレベルでより
細かく設定することも可能です。上記はクエリ単位でキャッシュの設定を行っている例です。
retriveModeやstoreModeのプロパティーを用いてデータ検索や保存時の対応を設定することがで
きます。
WAS V8.0 アナウンスメント・ワークショップ
37
07. Java EE 6 パート1
07.
07. Java EE 6 パート 1
JPA 2.0 ～ペシミスティック・ロックのサポート
®
オプティミスティック・ロック
– 他からのアクセスがないことを前提
– 更新対象が他のトランザクションによって書き換え
られていないかをJPAエンジンがチェック
– バージョン番号、最終更新時間によるチェック
データ読み取り
データ更新
データ読み取り
データ更新
OptimisticLock
Exception!
ペシミスティック・ロック
– 他からアクセスされる可能性を考慮したロック
– 更新対象に排他ロックをかけ、更新が終わるまで
他のトランザクションによる更新を禁止
– JPA2.0から正式にサポート
– lockメソッドの実行時に引数として指定
• LockModeType.PESSIMISTIC_WRITE
Lock!
データ読み取り
データ更新
データ読み取り
データ読み取り
データ更新
entityManager.lock(person, LockModeType.PESSIMISTIC_WRITE)；
© 2011 IBM Corporation
38
WAS V8.0 アナウンスメント・ワークショップ
JPA 2.0ではオプティミスティック・ロックだけでなくペシミスティック・ロックもサポートされるようになり
ました。オプティミスティック・ロックは他からのアクセスがないことを前提としたロックで、更新対象
が他のトランザクションによって書き換えられていないかをJPAエンジンがチェックし、書き換わって
いた場合は例外を発生させます。チェックにはバージョン番号を利用する方法と、最終更新時間を
利用する方法の2つがあります。
ペシミスティック・ロックは他からアクセスされる可能性を考慮したロックで、更新対象に排他ロック
をかけ、更新が終わるまでは他のトランザクションによる更新をさせません。ペシミスティック・ロック
はHibernateでは以前からサポートされていましたが、JPAはJPA 2.0から正式にサポートされるよう
になりました。JPA 2.0ではentityManagerのメソッドとしてlockメソッドが追加され、引数として
LockModeType.PESSIMISTIC_READかLockModeType.PESSIMISTIC_WRITEを指定します。
PESSIMISTIC_READは共有ロック、PESSIMISTIC_WRITEが排他ロックを指します。
WAS V8.0 アナウンスメント・ワークショップ
38
07. Java EE 6 パート1
07.
07. Java EE 6 パート 1
Bean Validation 1.0 ～アノテーションで実現するバリデーション
®
アノテーションを利用してバリデーションを実現
– Hibernate Validatorなどが実現していた機能
– Bean、フィールド、プロパティに制限
– nullチェック、数値の範囲のチェックなどが容易に実現可能
javax.validation.constraintsに定義されたアノテーション
– @AssertFalse、@AssertTrue
– @DecimalMax、@DecimalMin、@Max、@Min
– @Digits
– @Future、@Past (Date、Calenderクラスで示される時間のチェック)
– @Null、@NotNull
– @Pattern (正規表現によるチェック)
– @Size (文字列の長さや配列の数)
© 2011 IBM Corporation
39
WAS V8.0 アナウンスメント・ワークショップ
Bean ValidationはJava EE 6で新たに登場した機能です。もとはHibernate Validatorが実現していた
機能で、Beanやフィールド、プロパティに対するバリデーションをアノテーションを用いて行う機能で
す。そのため、バリデーションのためのコードは必要なくなり、 nullチェック、数値の範囲のチェック
などが容易に実現することができるようになりました。Java EE 6ではjavax.validation.constraintsに
上記のようなアノテーションが定義されています。True・Falseの判定や最大・最小値、桁数や時間
のチェック、Nullチェック、正規表現による文字列のチェック、文字列の長さ、配列の数など、多くの
パターンがアノテーションだけで実現可能です。
WAS V8.0 アナウンスメント・ワークショップ
39
07. Java EE 6 パート1
07.
07. Java EE 6 パート 1
Bean Validation 1.0 ～バリデーションのサンプル
®
import javax.validation.constraints.AssertTrue;
public class TestBean {
dataはtrueを想定
@AssertTrue(message="data must be true")
private boolean data;
public boolean isData() {
return data;
import javax.validation.*;
}
public void setData(boolean data) {
this.data = data;
}
@WebServlet(name="ValidServlet", urlPatterns={"/ValidServlet"})
public class ValidServlet extends HttpServlet {
protected void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
}
TestBean bean = new TestBean();
dataにfalseをセット
bean.setData(false);
ValidatorFactory validatorFactory = Validation.buildDefaultValidatorFactory();
Validator validator = validatorFactory.getValidator();
Set<ConstraintViolation<TestBean>> violations = validator.validate(bean);
for (ConstraintViolation<TestBean> violation : violations) {
message += violation.getInvalidValue()+":"+violation.getMessage() +
"<br>";
}
© 2011 IBM Corporation
40
WAS V8.0 アナウンスメント・ワークショップ
上記はアノテーションによるバリデーションを行ったサンプル・コードです。TestBeanクラスの
boolean型の変数dataは、アノテーション@AssertTrueによりTrueであることが求められます。そこで
別のクラスからTestBeanオブジェクトを生成し、dataをfalseに設定したとします。その後、
ValidatorFactoryからvalidatorを作成し、TestBeanオブジェクトを引数にvalidationを作成します。
dataをfalseに設定されていますので、バリデーションに違反していることになり、violationの
getInvalidValue()メソッドにより不正な値（この場合はfalse）と、getMessageメソッドにより違反した際
に出力するメッセージ（@AssertTrueのmessageで指定）が出力されます。Bean ValidationはJSFや
JPAなどで、入力値や出力値の検証に使用すると非常に有用ですが、バリデーションを行うために
はConstraintViolationを明示的に取得する必要がある点には注意して下さい。
WAS V8.0 アナウンスメント・ワークショップ
40
07. Java EE 6 パート1
07.
07. Java EE 6 パート 1
CDI 1.0 ～DIの統一
®
DIの統一化
サーブレットでのDI
WebサービスでのDI
CDI
統合
EJBでのDI
Context and
Dependency Injection
– @Injectアノテーションを用いたインジェクション
import org.example.HelloService;
@WebServlet(name = "HelloWorld", urlPatterns = { "/HelloWorld" })
public class HelloWorld extends HttpServlet {
@Inject HelloService helloService;
Inject !
– 実際に使用する際は
beans.xmlをモジュールに含める
• EJBはMETA-INF、WebモジュールはWEB-INF配下
• 中身は空でよい
package org.example;
import javax.inject.Named;
@Named
public class HelloService {
public void sayHello() {
System.out.println("Hello!");
}
}
© 2011 IBM Corporation
41
WAS V8.0 アナウンスメント・ワークショップ
CDIはContext and Dependency Injectionの略で、Java EE 6から登場した新機能です。CDIはサー
ブレットやEJB、Webサービスで使用したDIの作法を統一するもので、インジェクトしたいものに関わ
らず、全て@Injectアノテーションと@Namedアノテーションを用いてインジェクトが行えるようになりま
す。上の例では、HelloWorldサーブレットのフィールドにHelloServiceクラスがインジェクションされま
す。また、この機能を実際に使用する際には、EJBならMETA-INF、WebモジュールならWEB-INF配
下にbeans.xmlというファイルを配置する必要があります。XMLファイルの中身は空で構いません。
WAS V8.0 アナウンスメント・ワークショップ
41
07. Java EE 6 パート1
07.
07. Java EE 6 パート 1
CDI 1.0 ～スコープ
®
スコープもアノテーションで表現
– @RequestScoped
– @SessionScoped
– @ApplicationScoped
@SessionScoped
public class Counter implements Serializable {
private int count = 0;
@WebServlet(name="CounterServlet",
urlPatterns={"/CounterServlet"})
public class CounterServlet extends HttpServlet {
@Inject
private test.cdi.Counter c;
@SessionScoped
セッション内でデータ共有
Inject !
@PostConstruct
private void init(){
System.out.println(“Init");
}
@PreDestroy
private void destroy(){
System.out.println(“Destroy");
}
public int getCount(){
@Override
return ++count;
protected void doGet(HttpServletRequest request,
}
HttpServletResponse response)
}
throws ServletException, IOException {
…
out.println("<p>" + c.getCount() + "人目のアクセス</p>");
© 2011 IBM Corporation
42
WAS V8.0 アナウンスメント・ワークショップ
CDIの特長は、インジェクションするオブジェクトのスコープもアノテーションを用いて表現できること
です。上の例ではCounterServletにCounterクラスをインジェクションしています。Counterクラスは
@SessionScopedアノテーションが付けられていますので、セッション内でデータを共有することがで
きます。そのため、サーブレットではHttpSessionに関するコードは記載していませんが、セッション
スコープによる管理が実行できます。CDIのメリットは、インジェクションするオブジェクトのスコープ
定義をアノテーションベースで簡単に指定できることにもあると言えるでしょう。
WAS V8.0 アナウンスメント・ワークショップ
42
07. Java EE 6 パート1
07.
07. Java EE 6 パート 1
®
Java SE 6
© 2011 IBM Corporation
43
WAS V8.0 アナウンスメント・ワークショップ
この章では、WAS v8.0から新たに登場したガーベッジ・コレクションなど、Javaの動作環境としての
WAS v8.0の特長を紹介します。
WAS V8.0 アナウンスメント・ワークショップ
43
07. Java EE 6 パート1
07.
07. Java EE 6 パート 1
®
WAS V8 Java環境
JDKのバージョンはV7と同じくJava SE 6.0
–WAS v8.0 のバージョン
C:¥IBM¥WebSphere¥AppServer80¥java¥bin>java -version
java version "1.6.0"
Java(TM) SE Runtime Environment (build pwi3260_26fp1-20110419_01)
IBM J9 VM (build 2.6, JRE 1.6.0 Windows XP x86-32 20110418_80450 (JIT enabled, AOT enabled)
© 2011 IBM Corporation
44
WAS V8.0 アナウンスメント・ワークショップ
WAS v8.0はJava EE 6に対応していますが、JDKのバージョンはv7.0と同じくJava SE 6.0になります。
しかしbuildレベルが2.4から2.6にアップしています。
WAS V8.0 アナウンスメント・ワークショップ
44
07. Java EE 6 パート1
07.
07. Java EE 6 パート 1
®
ガーベッジ・コレクション・ポリシー
-Xgcpolicy:gencon
– ヒープを2つに分け、世代別にGCを実施
– アプリケーションの停止時間を抑制
– WAS V8のGCのデフォルト
New
重要
-Xgcpolicy:optthruput
– ヒープ全体でGCを管理
– 高いスループット
– 大容量のヒープサイズでは、アプリケーションの停止時間が長くなる
-Xgcpolicy:subpool
– 大規模環境用にオブジェクトのアロケーション・アルゴリズムを最適化
– V8では非推奨。結果はoptthruputと同じ
-Xgcpolicy:balanced
New
– GC効率を高めるために、領域を細分化し個別に管理
– 大規模なシステムでのアプリケーション・スループットを向上
– Win x86, Linux x86, AIX, Linux POWER, z/OS, z/Linuxでのサポート
– 参照圧縮を行う64bit環境で使用可能、ヒープサイズが4GB以上対象
© 2011 IBM Corporation
45
WAS V8.0 アナウンスメント・ワークショップ
WAS v8.0では新たなポリシーのガーベッジ・コレクション(GC)が追加されています。
-Xgcpolicy:genconはヒープを2つの領域に分け世代別にGCを行う方法です。この方法は大きな
ヒープサイズでもアプリケーションの停止時間を抑えられるという特長があります。WAS v7.0以前
は-Xgcpolicy:optthruputがデフォルトでしたが、8.0ではこの-Xgcpolicy:genconがデフォルトとなりま
した。マイグレーションの際は、アプリケーションの負荷テストを再度実施し、 GCの状況からXgcpolicy:genconとするか-Xgcpolicy:optthruputにするかを判断する必要があります。
-Xgcpolicy:optthruputはヒープ全体でGCを管理する方法です。 v7.0以前のデフォルトであり、高い
スループットが望まれますが、GCの際はアプリケーションは停止するため、大容量のヒープサイズ
では、アプリケーションの停止時間が長くなり、パフォーマンスが悪くなる傾向があります。
-Xgcpolicy:subpoolは複数のCPUを有する大規模環境用にオブジェクトのアロケーション・アルゴリ
ズムを最適化するGCですが、v8.0からは非推奨となっています。また、設定しても結果は
optthruputと同じになりますので、特にこちらを設定する必要はないでしょう。
-Xgcpolicy:balancedはWAS v8.0から登場した新しいGCポリシーです。 -Xgcpolicy:balancedは大規
模なヒープサイズを要する環境でもスループットを高めるため、領域を細分化し個別にGCを管理す
るという方法です。このポリシーは参照圧縮を行う64bit環境で、さらにWin x86, Linux x86, AIX,
Linux POWER, z/OS, z/Linuxでのサポートとなります。このGCはヒープサイズが4GB以上を対象と
しています。
WAS V8.0 アナウンスメント・ワークショップ
45
07. Java EE 6 パート1
07.
07. Java EE 6 パート 1
ガーベッジ・コレクションの大容量ヒープへの対応 ～optthruput
通常のGC(optthruput)
– ヒープ全体で1回のGC
– Mark & Sweep方式
®
Mark
使用中
使用中
使用中
使用中
– メリット
• 一般的な手法であり、
ヒープサイズが大きくない場合に有効
Sweep
– デメリット
• ヒープサイズに比例しGC時間が増加、
アプリケーションの停止時間が長くなる
使用中
使用中
使用中
使用中
Compaction
© 2011 IBM Corporation
46
WAS V8.0 アナウンスメント・ワークショップ
大容量のヒープサイズに対し、WASのGCがどのように対応してきたかを紹介します。
WASv6.0以前のGCは、ヒープ全体でGCを管理していました。GCの方式としてはMark&Sweep方式
が採用されていました。 Mark&Sweep方式では、新しいオブジェクトがヒープに配置できなかった場
合、まずヒープ内で使用中のオブジェクトをマークします(Markフェーズ)。次にマークされていない未
使用のオブジェクトを削除(Sweepフェーズ)して容量を確保しますが、さらにそれでも確保できない
場合は、使用中のオブジェクトを再編成し(Compactionフェーズ)、空き領域を確保します。この方式
で行うGCは一般的な手法であり、ヒープサイズが大きくない場合には有効な方法です。ただしヒー
プサイズに比例しGC時間が増加するため、ヒープサイズが大きいとGCにかかる時間はそれだけ
長くなり、それに従ってアプリケーションの停止時間も長くなるため、レスポンスタイムに影響があり
ます。
WAS V8.0 アナウンスメント・ワークショップ
46
07. Java EE 6 パート1
07.
07. Java EE 6 パート 1
ガーベッジ・コレクションの大容量ヒープへの対応 ～gencon
世代別GC(gencon)の登場
（WAS v6.1～）
– 若いインスタンスと、時間を経たインス
タンスを別々の領域に配置
– Nursery領域はさらに2つの領域に分割
され、Copying方式
– Tenured領域にはConcurrent Mark &
Sweep GC (CMS)方式
– メリット
Young（Nursery）
Eden
Survivor
®
Old（Tenured）
Survivor
Eden
• 領域を分割するため、
大容量のヒープサイズでも
効率よくGCの実行が可能
– デメリット
• Nursery領域が小さいと頻繁にGCを繰
り返し、パフォーマンスに影響
• Tenured領域でCompactionが発生する
と、GC時間が長くなる
Eden
Survivor
使用中
Eden
47
© 2011 IBM Corporation
Survivor
WAS V8.0 アナウンスメント・ワークショップ
既存のGCではパフォーマンスが出ないような大容量のヒープに対応するため、WAS v6.1では新た
なGCが登場しました。それが世代別GC(gencon)と呼ばれるGCポリシーです。
世代別GCでは、ヒープサイズを若いインスタンス用の領域(Nursery領域)と、時間を経たインスタン
ス用の領域(Tenured領域)の2つに分離し、個別に管理を行います。 Nursery領域ではさらに領域を
2つの領域に分け、Eden領域と呼ばれる片方の領域にオブジェクトを配置します。Eden領域がいっ
ぱいになると、必要なオブジェクトをチェックし、もう一方の領域(surviver領域)にコピーし、コピーさ
れなかったオブジェクトは削除されます。これがCopying方式と呼ばれるGCの方法です。
Survivor領域にオブジェクトがコピーされると、次はそちらをEden領域とし、こちらがいっぱいになる
ともう一方の領域にコピーし…というCopyingを繰り返し、それでも一定期間居座り続けるような使
用頻度の高いオブジェクトはTenured領域にコピーされます。 Tenured領域にコピーされたオブジェ
クトは以前のGCと同じ、Mark&Sweep方式でGCを行います。 Tenured領域のGCは、アプリケーショ
ンの動作を止めず、平行してMarkフェーズを実行するため、 Concurrent Mark & Sweep(CMS)方式
とも呼ばれます。
世代別GCはこのようにして、ヒープを2つに分割して個別にGCを行うため、通常のGC(optthruput)
よりも大容量のヒープサイズでも効率よくGCが実行できますが、Nursery領域が小さいと頻繁にGC
を繰り返し、パフォーマンスに影響する可能性もあります。またTenured領域でCompactionが発生
すると、GCにかかる時間が長くなるため、世代別GC(gencon)でも対応できないような、さらに大容
量のヒープサイズについて考慮が必要になりました。
WAS V8.0 アナウンスメント・ワークショップ
47
07. Java EE 6 パート1
07.
07. Java EE 6 パート 1
ガーベッジ・コレクションの大容量ヒープへの対応 ～balanced
®
バランスGC(balanced)の登場
（WAS v8.0～）
– 部分的ガーベッジ・コレクション（PGC)
• 同じサイズの領域に分割し、領域単位で管理
• オブジェクトは空の領域に
割り当てられ、いっぱいになると、
• 新しい空の領域に再編成
Eden（存続期間0）
Eden（存続期間0）
– グローバル・マーク・フェイズ（GMP）
• PGCとは別にヒープ全体を管理
• 長時間使われていないオブジェクトを
Concurrentにチェック
– バランスGCの制約
• 64 ビット・プラットフォーム
• 圧縮された参照が有効（-Xcompressedrefs）
存続期間１
– バランスGCの対象
• 4GB以上のヒープサイズ
– メリット
• 世代別GCでも対応が困難な
さらに大容量のヒープに対応
• GCの影響範囲を抑えられる
– デメリット
• チューニングが難しい
48
存続期間2
© 2011 IBM Corporation
WAS V8.0 アナウンスメント・ワークショップ
世代別GCでも対応が困難な、さらに大容量のヒープサイズに対し、 WAS v8.0では新たなGCが登
場しました。それがバランスGC(balanced)と呼ばれるGCです。
バランスGCではヒープを同じサイズの領域に細かく分割し、各領域単位でGCを管理します。ある領
域にオブジェクトが割り当てられ、いっぱいになると、新しい空の領域にオブジェクトをコピーし再編
成します。これが部分的ガーベッジ・コレクション(PGC)と呼ばれるGC方式です。元の領域はGC後
は空になりますので、新たなオブジェクトの領域として使用できますし、GCを行っていない他の領域
には影響を与えないので、GCによるアプリケーションへの影響も抑えることができます。
しかし、このように部分的ガーベッジ・コレクションを繰り返すと、領域ごとに小さなオブジェクトが分
散し、GCの効率が悪くなる可能性があります。それを防ぐために、バランスGCでは部分的ガーベッ
ジ・コレクションとは別に、長時間使われていないオブジェクトをヒープ全体でConcurrentにチェック
しています。これがグローバル・マーク・フェイズ(GMP)と呼ばれる仕組みです。部分的ガーベッジ・
コレクションとグローバル・マーク・フェイズの両方を行うことで、大容量のヒープでも効率よくGCを行
うことを可能にしています。
バランスGCを使用するには、64ビット・プラットフォームで圧縮された参照が有効である必要があり、
さらに4GB以上のヒープサイズを有する環境を対象にしていますが、これらの条件に当てはまる場
合は、非常に有効なGC方式と言えるでしょう。ただしバランスGCは分割された領域のサイズによっ
てGCの影響が大きく変わり、チューニングが難しいという面もあります。
WAS V8.0 アナウンスメント・ワークショップ
48
07. Java EE 6 パート1
07.
07. Java EE 6 パート 1
®
balanced GCの効果
同時アクセス数に対する平均/最大レスポンスタイムの測定例
Java Next Generation Garbage Collection （ Impact 2011 －Session Number: TAW-2303）より
負荷が高くなるほど差が顕著に現れる
© 2011 IBM Corporation
49
WAS V8.0 アナウンスメント・ワークショップ
上のグラフは、世代別GCとバランスGCを設定した環境での、同時アクセス数に対する平均/最大レ
スポンスタイムの測定例です。グラフより、同時アクセス数がそれほど多くなく、スレッド数も少ない
時にはレスポンスタイムにあまり差はありませんが、同時アクセス数が多くなるとバランスGCを採
用したほうがレスポンスタイムが良くなっていることがわかります。この結果より、大容量ヒープサイ
ズを有する環境では、負荷が高くなるほどバランスGCのほうがレスポンスタイムがよくなる傾向が
あると言えるでしょう。
WAS V8.0 アナウンスメント・ワークショップ
49
07. Java EE 6 パート1
07.
07. Java EE 6 パート 1
®
まとめ
© 2011 IBM Corporation
50
WAS V8.0 アナウンスメント・ワークショップ
WAS V8.0 アナウンスメント・ワークショップ
50
07. Java EE 6 パート1
07.
07. Java EE 6 パート 1
®
Java EE 6まとめ
開発がさらに容易なJava EE環境の実現
–プロファイル、プルーニングによる軽量化
–Webフラグメントに代表される拡張性
–アノテーションやCDIに示される、さらなるEase of Development
–機能の大幅な強化
• Servlet 3.0やJSF 2.0によるプレゼンテーション層の強化
• JPA 2.0やBean Validationによる永続化の強化
大規模ヒープを考慮したJava環境へ
–バランスGCなどに見られる、大規模ヒープを意識した新機能
© 2011 IBM Corporation
51
WAS V8.0 アナウンスメント・ワークショップ
当セッションのまとめは以上のようになります。Java EE 6は、プロファイルやプルーニングによる軽
量化、Webフラグメントに代表される拡張性、アノテーションやCDIに示されるEase of Development
の3つの特長を中心に、開発がさらに容易なJava EE環境の実現するものです。また、 Servlet 3.0
やJSF 2.0によるプレゼンテーション層の強化、JPA 2.0やBean Validationによる永続化の強化など
といって機能の大幅な強化により、開発者にとってさらに便利なものとなっています。
またWAS v8.0も、バランスGCといった機能の追加により、さらに大規模ヒープを考慮したJava環境
へと進化、発展を遂げています。
WAS V8.0 アナウンスメント・ワークショップ
51
07. Java EE 6 パート1
07.
07. Java EE 6 パート 1
®
参考文献
WebSphere Application Server v8 – Information Center
– http://publib.boulder.ibm.com/infocenter/wasinfo/v8r0/index.jsp
Impact 2011資料より
– Java EE 6: What's New, and How it All Works Together(TDP-1998)
– Servlet 3.0: What's New (TDP-2884)
– Enterprise JavaBeans Version 3.1, 3.0 technical overview(TDP-1375)
– JPA 2.0 Technical Overview with Demo(TDP-2442)
– Getting started with Java Contexts and Dependency Injection in Java EE6 (TDP-1085)
– Java Next Generation Garbage Collection Embracing Next-Generation Hardware and
Software(TAW-2303)
GC関連記事
– IBM Developer Kit and Runtime Environment, Java Technology Edition v6
• http://public.dhe.ibm.com/common/ssi/ecm/en/zsl03118usen/ZSL03118USEN.PDF
– Garbage collection in WebSphere Application Server V8,
• http://www.ibm.com/developerworks/websphere/techjournal/1106_bailey/1106_baile
y.html
• http://www.ibm.com/developerworks/websphere/techjournal/1108_sciampacone/110
8_sciampacone.html
© 2011 IBM Corporation
52
WAS V8.0 アナウンスメント・ワークショップ
WAS V8.0 アナウンスメント・ワークショップ
52
