websphere application server v8public.dhe.ibm.com/.../was_v8_ann_07_javaee6_part1.pdf– bean...

07. Java EE 6 パート1

WAS V8.0 アナウンスメント・ワークショップ 1

WebSphere Application Server V8.0WebSphere Application Server V8.0

アナウンスメント・ワークショップアナウンスメント・ワークショップ

© 2011 IBM Corporation

1 WAS V8.0 アナウンスメント・ワークショップWAS V8.0 アナウンスメント・ワークショップ

0707. . Java EE 6 Java EE 6 パートパート 11

®

Java EE 6 Java EE 6 パートパート11






®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の米国およびその他の国における登録商標です。






®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環境の変更点

まとめ

当セッションのアジェンダは以上になります。当セッションでは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」のセッションでご紹介します。






®

Java EE 6 登場の背景

この章では、JavaEE 6登場までの流れと開発における課題をお話します。






®Java EEの歴史

2009年12月リリースサイズの適正化、最新トレンドの実装により、さらに使い勝手よく開発できるJava環境の提供

2001 2002 2003 2004 2005 2006 2007 2008 2009

Java EE

2000 2010

最新トレンドを組み入れたJava EE へ軽量化、拡張性、EoD

エンタープライズシステムを支えるフレームワーク

J2EE 1.2

J2EE 1.3J2EE 1.4

EoDをテーマに、使いやすいJava EEへPOJO、DI/AOP、アノテーション

Java EE 5Java EE 6

WASWAS 4.0WAS 5.0

WAS 5.1WAS 6.0 WAS 6.1

WAS 7.0 WAS 8.0

2011

JavaEEサーバー GlassFish 3.0Apache Tomcat

7.0.6

2009.12

JBossEnterprise

Application

Platform 6

2009.12

2011.03

2012

2011.06

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に対応するとしています。






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

Java EE 6 Java SE

New and Update Technology

Pruning Target

Java EE 6の仕様は上記のようになります。Java EE 6では、ServletやJSFのメジャー・バージョンアップを中心に、Bean ValidationやCDIなどの新たな仕様も登場し、非常に大規模な仕様になっています。また、一部の機能はプルーニング対象として、次期Java EE 7で削除される可能性がある機能となっています。






®Java EE 6以前の課題

肥大化するJava EEの仕様– バージョンアップごとにJava EEの仕様が増加

– コンテナーの動作に影響– 必要な機能の整理

煩雑化する設定ファイル– アプリケーションの肥大化に伴う設定ファイルの煩雑化– フレームワーク固有の情報もJar外部のファイルに記載

増大するクラスファイル数– Java EEのレイヤー間の結合に必要なクラス（グルーコード）の存在

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のレイヤー間の結合のためだけに必要なクラスも存在します。レイヤーごとに分割して開発することにはメリットもありますが、接続のためだけに必要なクラスが数多く存在することで、アプリケーションの流れを読み辛くし、アプリケーションを大きくする一因にもなります。






®

Java EE 6の特長

この章では、Java EE 6の3つの特長を挙げ、開発の課題に対しJava EE 6がどのように改善されたかをお話します。






®Java EE 6の3つのキーワード

Rightsizing （軽量化）– 「プロファイル」の登場– 非推奨仕様の策定（プルーニング）

Extensibility （拡張性）– Webフラグメントによるライブラリーの柔軟な追加

Ease of Development （開発容易性）– アノテーションを活用したプログラミング– 簡略化されたEJBのパッケージング– Contexts and Dependency Injection（CDI）による

レイヤー間の柔軟な結合

Rightsizing

Extensibility

Ease of Development

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)によるレイヤー間の柔軟な結合などにより、開発をより容易にする機能を指します。






®プロファイルによるJava EEの軽量化

目的に応じ、Java EE 6完全版に対する一部の機能を「プロファイル」として定義– 特定のプロファイルを選択してコンテナーを実装することも可能

プロファイルの目的– Java EEコンテナーの起動時間を短縮

– 用途別に利用させ、使いやすさを促進

Oracle GlassFish Server 3.1 Web Profile (2011.2.28)– Web Profileだけを実装したアプリケーション・サーバー– Webプログラムに特化した機能だけを実装することで、

サーバーの起動時間を短縮

Java EE

Profile

主要機能の一部をコンテナーに実装

Rightsizing

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アプリケーションの開発性向上を図っています。






®Java EE ProfileとWeb Profile

Java EE 6で定義されてるProfile– Java EE Profile

• Java EEの全仕様を含む

– Web Profile• Webアプリケーションの実行に必要な仕様だけを含む

ベンダーが独自に定義し、機能を実装しても構わない

Rightsizing

Web Profile

Web Application TechnologiesJava Servlet 3.0JavaServer Faces (JSF) 2.0JavaServer Pages 2.2and Expression Language (EL) 1.2

A Standard Tag Library for JavaServer Pages 1.2Debugging Support for Other Languages 1.0

Java EE Profile

その他、定義されている全仕様を実装

Enterprise Application TechnologiesContexts and Dependency Injection

for the Java EE Platform 1.0Dependency Injection for JavaEnterprise JavaBeans 3.1 (EJB Lite)Java Persistence API 2.0Common Annotations for the Java Platform 1.1Java Transaction API (JTA) 1.1Bean Validation 1.0

EJB Lite (EJBの軽量版)

プロファイルはベンダーが独自に定義し、独自にコンテナーに実装しても構いませんが、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など、よく使用される機能のみを抜き出して定義したものです。






®プルーニング

非推奨機能の策定–必要なJava EEの機能を見直し、

互換性のための機能や使用頻度の低い機能をプルーニング対象に

–次期版(Java EE 7)で「削除」「必須」「削除提案のまま」を決定

Java EE 6でプルーニング対象に指定された機能–EJB2.X Entity Beans–JAX-RPC–JAXR–Java EE Application Development (JSR-88)

Rightsizing

RightSizingにおけるもうひとつの代表が「プルーニング」です。

プルーニングとは本来、余分な枝や根を切りおろすという意味ですが、Java EE 6では、互換性のためだけに残している機能やあまり使用頻度の低い機能をプルーニング対象として定義しています。プルーニング対象となった機能は、次期のJava EEのリリースの際に「削除」「必須」「削除提案のまま」を決定され、削除対象となると、次期バージョンでは削除されます。Java EE 6ではプルーニング対象となった機能として上記の4つがあります。これらの機能はJava EE 6では使用可能ですが、次期バージョンでは削除される可能性があるため、バージョンアップの際には考慮が必要です。






®Webフラグメント

Servlet 3.0の新機能– 固有の定義はJarファイルで完結

– フレームワークの追加削除をしやすく

Webフラグメント登場の背景– アプリケーションにフレームワークを使用するためにJarファイルをlib配下に– 各フレームワークで必要なサーブレットの定義情報などは、一括してweb.xmlに記述– 複数のフレームワークを使用することにより、web.xmlのサイズも増加

Extensibility

WEB-INFweb.xml

lib

webApp.war

web.xml

Framework1.jar

Framework2.jar

Extensibilityの代表的な機能が「Webフラグメント」です。WebフラグメントはServlet 3.0の新機能のひとつで、フレームワーク固有の定義をJarファイル内部で完結させ、外部の設定ファイルを使用しないことで、フレームワークの追加や削除を柔軟に行うことを目指した機能です。

Webフラグメントが登場した背景には、設定ファイルの煩雑さ防止があります。アプリケーション開発では、フレームワークが用いられるケースも多々ありますが、フレームワークを使用するためには、libディレクトリの配下にJarファイルを配置する必要があります。しかし、StrutsではActionServlet、Spring MVCではDispatcherServletというように、フレームワークが固有で使用するサーブレットは決まっており、それらのサーブレットを使用するためには、URLや初期値の設定を一括してweb.xmlというJarファイルの外部で指定しなくてはいけません。そのため、複数のフレームワークを使用することにより、web.xmlにも多くの記載が必要となり、見た目も煩雑になります。さらに、フレームワークを削除する際にはweb.xmlから定義の削除も必要となり、フレームワークの追加削除にかかる手間となります。






®Webフラグメントによるモジュールの柔軟性向上

Webフラグメントができること– jarファイル側でweb-fragment.xmlを用意

– そのフレームワークに必要なweb.xmlへの設定をweb-fragment.xmlに記述

– web.xmlへの記述を削減

– 削除の際もweb.xmlへの変更は不要

Extensibility

WEB-INFweb.xml

lib

webApp.war

Framework2.jarMETA-INF/web-fragment.xml

Framework1.jarMETA-INF/web-fragment.xml

これらを解決する機能がWebフラグメントです。Webフラグメントとは、設定ファイルを各Jarファイルごとに用意することで、モジュール全体の設定ファイルへの記述を軽減する機能です。Jarファイル内部ではMETA-INFの下にweb-fragment.xmlという設定ファイルを用意し、ここに必要な設定を記述します。モジュール全体で持つweb.xmlは、各Jarファイル内のweb-fragment.xmlを統合し、ひとつのweb.xmlとして機能します。この機能を用いることで、フレームワークの追加削除によるweb.xmlへの記述の追加削除は必要なくなるため、柔軟にフレームワークの追加削除が行えるだけでなく、web.xmlへの記述量も削減できます。






®アノテーションを活用したプログラミング

アノテーションを活用し、設定ファイルの必要性を削減

– 目的はアプリケーションの規模増大による、設定ファイル肥大化の防止

アノテーションベースのサーブレットの例

– Servlet 3.0からはサーブレット・マッピングや、初期化パラメータの指定もアノテー

ションで可能に

WEB-INFweb.xml

classes

webApp.war

Servlet A

Servlet B

web.xml

サーブレットの定義、マッピング初期化パラメータなどをweb.xmlに記載

WEB-INF

classes

webApp.war

Servlet A

Servlet B

必要な情報はアノテーションを使って各コード内に記載

Ease of Development

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はオプション扱いとなっており、必須ではなくなっています。






®簡易化されたパッケージング

EJBのパッケージング–WarファイルにEJBを含めることが可能

–EJBを含むJarファイルが不要に

–インターフェースも不要

WEB-INF/web.xmlWEB-INF/classes/com/ise/EJBSampleServlet.class

com/ise/EJBSampleBean.classcom/ise/EJBSample.class

EJBSample_web.war

EJBSample_ejb.jar

EJB 3.1

Ease of Development

EJB 3.0

ビジネス・ロジック

インターフェース

EJBクライアント

WEB-INF/classes/com/ise/EJBSampleServlet.classcom/ise/EJBSampleBean.class

EJBSample.war

Java EEが6にバージョンアップしたことにより、対応するEJBも3.0から3.1にバージョンアップしました。EJB 3.1では、Webモジュール内にEJBを含めることが可能になり、EJBを含むJarファイルは不要になりました。また、インターフェイスも不要になったために、Webモジュール内でクライアントとBeanだけが存在するという非常にシンプルな構成でEJBを使用することができます。






®レイヤー間のシームレスな連携

Java EE 5が実施したこと– JSFやJPAを標準化

– 各レイヤーにおいて切り分け

Java EE 5の課題

– 結合するための処理が必要

Java EE 6が実施したこと– 直接JSFから

EJBやJPAにアクセスし、結合するためだけのクラスは不要に

– アノテーションを用いることで、設定ファイルも最小限に

Ease of Development

Java EE 5

JSF EJB 3.0

JSP ManagedBean

SessionBean

JPAJPA Entity

実行

出力

DB

JSPfaces-

config.xml

Java EE 6

JSF EJB 3.0XHTML Session

Bean

JPAJPA Entity

実行

出力

DB

XHTML

さらにJava EE 6は、レイヤー間のシームレスな連携も考慮されています。Java EE 5ではJSFやJPAを標準化することで、プレゼンテーションはJSF、ビジネスロジックはEJB、データアクセスはJPAといったように、各レイヤー間で仕様を切り分けて開発を行うことが可能になりました。しかし、各コンポーネントには固有の作法があったために、連携するための処理は容易ではありませんでした。また、ビジネスロジックとは関係なく、結合のためだけに必要なクラスもあり、アプリケーションを複雑化する一因でもありました。

Java EE 6ではJBoss Seamを踏襲し、各コンポーネント間のスムーズな連携も行えるようになりました。JSFからは直接EJBやJPAにアクセスすることができ、結合するためだけに必要だったクラスは不要になりました。さらにアノテーションを用いることで、設定ファイルも必要最小限に抑えることが可能です。






®

Java EE 6 各新機能

この章では、Servlet 3.0、EJB3.1、JSF2.0、JPA2.0のバージョンアップによる新機能と、Bean Validation 1.0、CDI 1.0といったJava EE 6から新たに登場した仕様についてお話します。






®Java EE 6 各新機能紹介

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– スコープ定義

New

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の仕様を統一化し、スコープ定義をアノテーションベースで簡単に行える機能です。






®Servlet 3.0 ～新機能

Ease of Development–アノテーションやWebフラグメントの登場

セキュリティー–Servletによるログインログアウトの実現

非同期処理–Servletによる非同期処理の実現

拡張性の向上（Pluggability）–プログラムによるWebコンテナーの拡張

–サーブレットやフィルターの動的な追加

Servlet 3.0の新機能は以上のようになります。さらなるEase of Developmentとして、構成のためのアノテーションが大きく追加され、拡張性を高めるためにWebフラグメントが登場しました。さらに、Servletによるログイン・ログアウトや非同期処理も実現可能になり、Webコンテナーを拡張した初期化処理や、サーブレットやフィルターを動的に追加することも可能になりました。






®Servlet 3.0 ～アノテーションと拡張性向上

アノテーションベースのプログラミングを推進– web.xmlをオプション化

– アノテーションの設定はweb.xmlで上書き

優れた拡張性– web-fragment.xmlによるweb.xmlの分割

•Jarファイル内でのweb.xmlの設定が可能

– META-INF/resourcesディレクトリ

•静的コンテンツを保管

•コンテキストルートでアクセス可能

初期パラメーターの定義@WebInitParam

リスナーの定義@WebListener

フィルターの定義@WebFilter

Servletの定義（name、urlpattern）@WebServlet

用途アノテーション

Framework1.jar

META-INF/web-fragment.xml

Framework1.jar

META-INF/resources/sample.html

http://www.aaa.com/context_root/sample.html

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ファイル内でMETA-INFのresourcesディレクトリに保管された静的コンテンツを、コンテキストルートでアクセスすることも可能になりました。






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

…（略）

}

Servlet 3.0では、formタグで行っていたフォーム認証をサーブレットで行うことも可能になりました。認証を実現するためのメソッドとして、HttpServletRequestにauthenticate、login、logoutというメソッドが追加されました。また@ServletSecurityというアノテーションも追加され、ロールベースのアクセス制御をアノテーションで行うことも可能になりました。






®Servlet 3.0 ～非同期処理

非同期リクエスト処理用のモデルを提供Servletの実行スレッドを早期解放

非同期処理を行うスレッドはリクエストの情報を保有し、レスポンスを返す

startAsync(req,resp)+ start()

doGet()

response

Servlet 別スレッド

時間のかかる処理

doGet()Servlet

response

時間のかかる処理

Servlet 3.0

Servlet 3.0では非同期リクエストを処理するための仕組みを提供しています。同期処理では、時間のかかる処理を行っている間、サーブレットの実行スレッドは常に占有された状態となり、他のリクエストを処理することができません。Servlet 3.0の非同期処理では、サーブレットがリクエストを受けると、別スレッドに処理を移管させ、リクエストを受けたサーブレットはそこで処理を終了します。その後、時間のかかる処理を別スレッドで実行させ、レスポンスは別スレッドから返します。そうすることで、サーブレットの実行スレッドは早期に開放され、他のリクエスト処理のために待機させることが可能です。






®Servlet 3.0 ～非同期処理の例

@WebServletの引数 asyncSupported=true に設定

protected void doGet(HttpServletRequest request,

HttpServletResponse response) throws ServletException, IOException {

System.out.println("サーブレット開始");

//①AsyncContext取得AsyncContext actx =

request.startAsync(request,response);

//②非同期処理実行開始actx.start(new Async(actx));

System.out.println("サーブレット終了");

}

public static class Async implements Runnable {AsyncContext ctx;public Async(AsyncContext ctx) {

this.ctx = ctx;}

@Override//③runメソッドの実行public void run() {

// ④時間のかかる処理…

//レスポンスの出力java.io.PrintWriter writer =

ctx.getResponse().getWriter()writer.println(“<html>処理終了</html>");writer.close();

//⑤同期化処理の終了ctx.complete();

}}

非同期処理を行うサーブレットの例です。非同期処理を行うサーブレットは@WebServletの引数としてasyncSupportedをtrueに設定する必要があります。サーブレットでは、まずHttpServletRequestのstartAsyncメソッドを実行し、AsyncContextを取得します。取得したAsyncContextのstartメソッドを実行することで、非同期処理が実行され、サーブレットは処理を終了します。startメソッドは非同期処理を行うクラスを引数にとります。非同期処理を行うクラスはRunnableをインプリメントし、runメソッドを実装します。 startメソッドにより、非同期処理を行うクラスのrunメソッドが実行され、時間のかかる処理をここで実行します。その後にブラウザにレスポンスとして返す内容を記載し、処理の最後にAsyncContextのcompleteメソッドにより同期化処理を終了させます。






®Servlet 3.0 ～プログラマティックな初期化処理

ServletContainerInitializer– ServletContainerInitializerインターフェイスをインプリメントし、onStartupメソッドを実装– コンテナーがモジュールをロードした際、onStartupメソッドが実行され、

初期化処理が実行可能– サーブレットの登録やマッピングなどをonStartup内で動的に登録することも可能

– META-INF/servicesにjavax.servlet.ServletContainerInitializerという名のファイルを作成• 中身は実装クラスを記載

public class ServletContainerInitializerImpl implements ServletContainerInitializer {

@Overridepublic 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");

}

｝

Servlet 3.0からServletContainerInitializerというインターフェイスが追加されました。このインターフェイスをインプリメントしたクラスは、onStartupメソッドを実装します。onStartupメソッドはコンテナーがモジュールをロードした際に実行されますので、サーブレットの初期化処理を行うことが可能です。また、Servlet 3.0ではサーブレットの登録やマッピングなどを動的に行うことができますので、onStartupメソッド内でサーブレットやリスナーの登録を行うことも可能です。

この機能を用いる際には、WebモジュールのMETA-INF/servicesディレクトリにjavax.servlet.ServletContainerInitializerというファイルを作成しておく必要があります。このファイルにはServletContainerInitializerをインプリメントしたクラスを記載しておくことで、コンテナーの起動時にonStartupメソッドが実行されます。






®EJB 3.1 ～新機能

シンプルなプログラミングモデル–EJB Liteの登場

–シングルトンセッションBeanの登場

–より利用しやすいタイマーサービス

–グローバルJNDI名の統一

単体テストの容易な実現–JavaSE環境にEJBコンテナーを組み込んで単体テストを実行

EJB3.1の新機能は以上のようになります。EJB3.1では、よりシンプルなプログラミングモデルを実現するために、さまざまな機能が追加されました。Webプロファイルで採用されたEJB Liteをはじめ、Webモジュール内で使用可能なパッケージング。シングルトンセッションBean。より開発者にとってわかりやすいタイマーサービス、グローバルJNDI名の採用などがその代表です。また、単体テストを容易に実現するために、Java SE環境にEJBコンテナーを組み込んで単体テストを実行することも可能になりました。






®EJB 3.1 ～EJB概要

EJB(Enterprise Java Bean)の目的– ビジネス・ロジックの分離– トランザクションの管理と

分散オブジェクト技術の統合

EJB（EJBコンテナー）ができること– トランザクション管理– アクセス制御– タイマーサービス– リモート呼び出し（分散オブジェクト処理）– データの永続化

WEB-INF/web.xmlWEB-INF/classes/com/ise/EJBSampleServlet.class


EJBSample_web.war

EJBSample_ejb.jar

EJB 2.1

EJBの開発を困難にしている理由– 本質的なビジネス・ロジックとは関係ない

作成物、実装コードが多い– 継承、実装の作法が複雑

WEB-INF/web.xmlWEB-INF/classes/

com/ise/EJBSampleServlet.class

com/ise/EJBSampleBean.classcom/ise/EJBSample.classcom/ise/EJBHome.class

EJBSample_web.war

EJBSample_ejb.jar

EJB 3.0

EJB 3.0

ビジネス・ロジック（implements SessionBean)

インターフェース（extends EJBObject)

Homeインターフェース（extends EJBHome)

インターフェイス@Remoteアノテーション

ビジネス・ロジック@Statefulアノテーションimplements EJBSample)

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固有のクラスやインターフェースを継承する必要なくなりました。






®EJB 3.1 ～EJB Liteとパッケージの簡略化

EJB Lite– Web Profileで利用されている– 簡略化されたEJBの機能のみを定義

パッケージの簡略化– Webモジュールのみ。Jarは不要

– インターフェイスも不要– JavaEE 5同様のパッケージングも可能

Local Session BeansAnnotations / ejb-jar.xmlCMT / BMTDeclarative SecurityInterceptorsJPA 2.0JTA 1.1

Message Driven BeansEJB Component Web

Service EndpointsRMI-IIOP Interoperability2.x/3.x Remote View2.x Local ViewTimer ServiceCMP / BMP

EJB Lite

EJB完全版

WEB-INF/classes/com/ise/EJBSampleServlet.classcom/ise/EJBSampleBean.class

EJBSample.warWEB-INF/web.xmlWEB-INF/classes/

com/ise/EJBSampleServlet.class


EJBSample_web.war

EJBSample_ejb.jarEJB 3.1

EJB 3.0EJB 3.1

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も実行させることが可能です。






®EJB 3.1 ～シングルトンセッションBean、タイマーサービス

シングルトンセッションBean– アプリケーションで唯一のインスタンスを保証

– デフォルトではコンテナーがアクセス制御を実行• @ConcurencyManagement(BEAN)を指定し、開発者がアクセス制御をコードで行うことも可能

• @Lock(READ) 複数アクセスの読み込み許可

• @Lock(WRITE) 書き込みは単一アクセス

タイマーサービス– カレンダー表記での時間指定

– @Scheduleアノテーションでの指定

// 月～金の正午

ScheduleExpression expr = new ScheduleExpression().dayOfWeek(“Mon-Fri”).hour(12);timerSvc.createTimer(expr, null);

@Schedule(dayOfWeek=”Mon”) // 毎月曜日深夜0:00@Schedule(minute=”15”, hour=”3”, dayOfWeek=”Mon-Fri”) // 月～金の午前3:15

EJB3.1からシングルトンセッションBeanが新機能として追加されました。シングルトンセッションBeanはアプリケーションで唯一のインスタンスであることを保証するセッションBeanで、デフォルトではEJBコンテナーがBeanの管理を行いますが、 @ConcurencyManagement(BEAN)を指定し、開発者がアクセス制御をコードで行うことも可能です。コンテナーがアクセスを制御する場合、複数アクセスの読み込みを許可するか、単一アクセスの書き込みのみ許可するか、といった制御を@Lockアノテーションを用いて指定します。

タイマーサービスは以前のEJBでもありましたが、EJB3.1では、カレンダー表記で時間の指定がよりわかりやすくなりました。例えば平日の正午にタイマーをセットする場合、 dayOfWeek(“Mon-Fri”).hour(12)と指定します。また、@Scheduleアノテーションを用いたタイマー定義も可能になりました。






®EJB 3.1 ～グローバルJNDI名の標準化

グローバルJNDI名の統一

– グローバル・レベル

java:global/[app-name]/module-name/ejb-name– アプリケーション・レベル

java:app/module-name/ejb-name– モジュール・レベル

java:module/ejb-name

@Statelesspublic class HelloBean implements Hello {

public String sayHello(String message) {

return “Hello ! ”+ message ;

}

}

java:global/application/hello/HelloBean

java:app/hello/HelloBean

java:module/HelloBean

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名の変更は必要なくなります。






®EJB 3.1 ～組み込み可能なEJBコンテナー

EJBはEJBコンテナーが必要なため、単体テストは困難

EJB 3.1からはJavaSEにEJBコンテナーを組み込んで使用可能– JUnitなどを用いて単体テストが可能

– 開発向けの機能

public void testSayHello() {

Map map = new HashMap();

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

e.printStackTrace();

｝

｝

HashMapとしてEJBコンテナーの情報を入力

glassfishの場合p.put(“org.glassfish.ejb.embedded.glassfish.instance.root”, “/Applications/GlassFish/glassfishv3-webprofile/

glassfish/domain/domain1”);

EJBContainerクラスのContextよりEJBをlookup

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の単体テストを行えるため、使い勝手の良い機能と言えるでしょう。






®JSF 2.0 ～新機能

Facelets–JSP+JSFタグからXHTML+JSF属性に変更

Ajaxのサポート–<f:ajax>タグによりJavaScriptを動的に生成

アノテーション対応–マネージドBeanがPOJO＋アノテーションだけで作成可能

–JSFの設定ファイルfaces-config.xmlのオプション化

Bean Validation対応

JSF 2.0の新機能は以上のようになります。Java EE 6により、JSFは1.2から2.0へとバージョンアップしましたが、大きな新機能としては、JSPからJSFのタグを利用して画面表示させていた部分をXHTMLベースで行う「Facelets」の登場が挙げられます。その他、 AjaxのサポートによりJavaScriptを動的に生成できるようになった点や、アノテーションによりJSFの設定ファイルがオプション化された点、Bean Validationへの対応などが挙げられます。






®JSF 2.0 ～JSF概要

Java EE標準のUIコンポーネント・フレームワーク– UIコンポーネントを視覚的に扱い、Webアプリケーションの画面開発が容易に可能

JSFの構成要素– FacesServlet

• リクエスト処理を受け付けるサーブレット

– Lifecycleクラス• FacesServletクラスから呼ばれ、処理のコントロールを実施

– マネージドBean• Webブラウザからの入出力値を保持し、処理を実行するBeanクラス

– JSFタグ• JSFが提供するタグライブラリ

– UIコンポーネント• テキストフィールド、サブミットボタンなど、ユーザーとの入出力インターフェイスを構成する部品群

JSF Application

FacesServlet実行

出力

JSP

HTTPリクエスト Lifecycle class

Managed Bean

HTTPレスポンス

UI ComponentJSF Tag

生成

参照・更新

参照

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コードを出力します。






®JSF 2.0 ～Facelets

JSPによる表示の課題を解決– コードの編集、保存、再読み込みを行うたびに、JSPコンパイラがServletを生成し実

行するのはオーバーヘッドになる

FaceletsはXHTMLを使用– XMLをSAXにより解析

テンプレート機能– 画面上のヘッダやフッタ、左ペインなど、共通部分をテンプレートとして記載– 開発効率やメンテナンス性を向上

JSF2.0の新機能のひとつにFaceletsがあります。JSF1.2ではJSPを用いて画面表示を行っていましたが、コードの編集、保存、再読み込みの度にJSPコンパイラがServletを生成しServletを実行することで画面表示を行うため、オーバーヘッドが高いという課題がありました。そこでFaceletsではXHTMLを使用し、XMLをSAXにより解析を行うことで出力のオーバーヘッドを軽減しています。また、Faceletsは画面上の共通部分をテンプレートとして扱うこともできるため、開発効率やメンテナンス性を向上できます。






®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として各エンティティに組み込んで使用する

JPA 2.0の新機能は以上のようになります。 Java EE 6により、JPAは1.0から2.0へとバージョンアップしました。新機能としてはEmbeddablesの多段構成やJPQLの更新。各ランタイムAPIの更新、キャッシュの強化、ペシミスティック・ロックのサポート、Bean Validationへの対応などが挙げられます。このセッションでは、新機能としてキャッシュの強化とペシミスティック・ロックのサポートについて紹介します。






®JPA 2.0 ～JPA概要

Java EE標準のO/Rマッピング技術– ベースはPOJO– javax.persistenceパッケージで定義されたAPI– JPQL(Java Persistence Query Language)によるDB操作

JPAの構成要素– エンティティ・クラス

• データベースの1テーブルに相当し、永続化可能なJavaクラス

– エンティティ・マネージャー• エンティティを操作するためにJPAが提供するインターフェース。レコードの取得、更新、削除を実行

– パーシスタンス・コンテキスト• エンティティ・インスタンスの集合。DBと同期を取ることが保証された、レコードのキャッシュ

RDBに格納されているデータをオブジェクトとして直感的に扱う1レコード＝1つのJavaオブジェクト

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エンジンがデータベースに対し指定された操作を行います。エンティティ・マネージャーによって取得されたエンティティ・オブジェクトの集合をパーシスタンス・コンテキストと呼びます。パーシスタンス・コンテキストはデータベースのレコードの内容をキャッシュしたものですが、データが更新された場合もデータベースと同期を取ることが保証されたキャッシュになります。






®JPA 2.0 ～二次キャッシュ

一次キャッシュ– 単一のパーシスタンス・コンテキストのエンティティに対するキャッシュ– エンティティ・マネージャーが管理

二次キャッシュ– 複数のパーシスタンス・コンテキストのエンティティのキャッシュを共有– JPAの設定ファイルpersistence.xmlの<shared-cache-mode>で設定

– クエリレベルでの設定例

@Cacheable(false)の指定があるもののみキャッシュしないDISABLE_SELECTIVE

@Cacheable(true)の指定があるもののみキャッシュENABLE_SELECTIVE

キャッシュ無効NONE

全てキャッシュ（デフォルト）ALL

動作設定

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に反映）

JPA 2.0では、パーシスタンス・コンテキスト内のエンティティに対するキャッシュが強化されています。JPA 1.0では、ひとつのパーシスタンス・コンテキストのエンティティに対するキャッシュのみがサポートされていましたが、JPA 2.0では、複数のパーシスタンス・コンテキストについてエンティティのキャッシュを共有することが可能になりました。キャッシュの設定はJPAの設定ファイルpersistence.xmlの<shared-cache-mode>タグで以上のように設定できます。デフォルトでは全てキャッシュするように設定されています。また、キャッシュの設定はエンティティやクエリレベルでより細かく設定することも可能です。上記はクエリ単位でキャッシュの設定を行っている例です。retriveModeやstoreModeのプロパティーを用いてデータ検索や保存時の対応を設定することができます。






®JPA 2.0 ～ペシミスティック・ロックのサポート

オプティミスティック・ロック– 他からのアクセスがないことを前提

– 更新対象が他のトランザクションによって書き換えられていないかをJPAエンジンがチェック

– バージョン番号、最終更新時間によるチェック

ペシミスティック・ロック– 他からアクセスされる可能性を考慮したロック

– 更新対象に排他ロックをかけ、更新が終わるまで他のトランザクションによる更新を禁止

– JPA2.0から正式にサポート

– lockメソッドの実行時に引数として指定• LockModeType.PESSIMISTIC_WRITE

entityManager.lock(person, LockModeType.PESSIMISTIC_WRITE)；

データ読み取りデータ読み取り

データ更新

データ更新データ読み取り

Lock!

データ読み取りデータ読み取り

データ更新データ更新

OptimisticLockException!

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が排他ロックを指します。






®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 (文字列の長さや配列の数)

Bean ValidationはJava EE 6で新たに登場した機能です。もとはHibernate Validatorが実現していた機能で、Beanやフィールド、プロパティに対するバリデーションをアノテーションを用いて行う機能です。そのため、バリデーションのためのコードは必要なくなり、 nullチェック、数値の範囲のチェックなどが容易に実現することができるようになりました。Java EE 6ではjavax.validation.constraintsに上記のようなアノテーションが定義されています。True・Falseの判定や最大・最小値、桁数や時間のチェック、Nullチェック、正規表現による文字列のチェック、文字列の長さ、配列の数など、多くのパターンがアノテーションだけで実現可能です。






®Bean Validation 1.0 ～バリデーションのサンプル

import javax.validation.constraints.AssertTrue;

public class TestBean {

@AssertTrue(message="data must be true")private boolean data;public boolean isData() {

return data;

}

public void setData(boolean data) {

this.data = data;

}

}

dataはtrueを想定

import javax.validation.*;

@WebServlet(name="ValidServlet", urlPatterns={"/ValidServlet"})

public class ValidServlet extends HttpServlet {

protected void doGet(HttpServletRequest request, HttpServletResponse response)

throws ServletException, IOException {

TestBean bean = new TestBean();

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

}

dataにfalseをセット

上記はアノテーションによるバリデーションを行ったサンプル・コードです。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を明示的に取得する必要がある点には注意して下さい。






®CDI 1.0 ～DIの統一

DIの統一化

– @Injectアノテーションを用いたインジェクション

– 実際に使用する際はbeans.xmlをモジュールに含める

• EJBはMETA-INF、WebモジュールはWEB-INF配下

• 中身は空でよい

サーブレットでのDI

EJBでのDI

WebサービスでのDI CDIContext and

Dependency Injection

統合

import org.example.HelloService;

@WebServlet(name = "HelloWorld", urlPatterns = { "/HelloWorld" }) public class HelloWorld extends HttpServlet {

@Inject HelloService helloService;

package org.example; import javax.inject.Named;

@Named public class HelloService {

public void sayHello() {System.out.println("Hello!");

} }

Inject !

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ファイルの中身は空で構いません。






®CDI 1.0 ～スコープ

スコープもアノテーションで表現– @RequestScoped– @SessionScoped– @ApplicationScoped

@WebServlet(name="CounterServlet", urlPatterns={"/CounterServlet"})

public class CounterServlet extends HttpServlet {

@Injectprivate test.cdi.Counter c;

@Overrideprotected void doGet(HttpServletRequest request,

HttpServletResponse response) throws ServletException, IOException {…out.println("<p>" + c.getCount() + "人目のアクセス</p>");

@SessionScopedpublic class Counter implements Serializable {

private int count = 0;

@PostConstructprivate void init(){

System.out.println(“Init");}@PreDestroyprivate void destroy(){

System.out.println(“Destroy");}

public int getCount(){return ++count;

}}

Inject !

@SessionScopedセッション内でデータ共有

CDIの特長は、インジェクションするオブジェクトのスコープもアノテーションを用いて表現できることです。上の例ではCounterServletにCounterクラスをインジェクションしています。Counterクラスは@SessionScopedアノテーションが付けられていますので、セッション内でデータを共有することができます。そのため、サーブレットではHttpSessionに関するコードは記載していませんが、セッションスコープによる管理が実行できます。CDIのメリットは、インジェクションするオブジェクトのスコープ定義をアノテーションベースで簡単に指定できることにもあると言えるでしょう。






®

Java SE 6

この章では、WAS v8.0から新たに登場したガーベッジ・コレクションなど、Javaの動作環境としてのWAS v8.0の特長を紹介します。






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

WAS v8.0はJava EE 6に対応していますが、JDKのバージョンはv7.0と同じくJava SE 6.0になります。しかしbuildレベルが2.4から2.6にアップしています。






®ガーベッジ・コレクション・ポリシー

-Xgcpolicy:gencon– ヒープを2つに分け、世代別にGCを実施

– アプリケーションの停止時間を抑制– WAS V8のGCのデフォルト

-Xgcpolicy:optthruput– ヒープ全体でGCを管理

– 高いスループット– 大容量のヒープサイズでは、アプリケーションの停止時間が長くなる

-Xgcpolicy:subpool– 大規模環境用にオブジェクトのアロケーション・アルゴリズムを最適化– V8では非推奨。結果はoptthruputと同じ

-Xgcpolicy:balanced– GC効率を高めるために、領域を細分化し個別に管理

– 大規模なシステムでのアプリケーション・スループットを向上– Win x86, Linux x86, AIX, Linux POWER, z/OS, z/Linuxでのサポート– 参照圧縮を行う64bit環境で使用可能、ヒープサイズが4GB以上対象

重要

New

New

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以上を対象としています。






®ガーベッジ・コレクションの大容量ヒープへの対応～optthruput

通常のGC(optthruput)– ヒープ全体で1回のGC– Mark & Sweep方式

– メリット

• 一般的な手法であり、ヒープサイズが大きくない場合に有効

– デメリット

• ヒープサイズに比例しGC時間が増加、

アプリケーションの停止時間が長くなる

使用中使用中使用中使用中

使用中使用中使用中使用中

Mark

Sweep

Compaction

大容量のヒープサイズに対し、WASのGCがどのように対応してきたかを紹介します。

WASv6.0以前のGCは、ヒープ全体でGCを管理していました。GCの方式としてはMark&Sweep方式が採用されていました。 Mark&Sweep方式では、新しいオブジェクトがヒープに配置できなかった場合、まずヒープ内で使用中のオブジェクトをマークします(Markフェーズ)。次にマークされていない未使用のオブジェクトを削除(Sweepフェーズ)して容量を確保しますが、さらにそれでも確保できない場合は、使用中のオブジェクトを再編成し(Compactionフェーズ)、空き領域を確保します。この方式で行うGCは一般的な手法であり、ヒープサイズが大きくない場合には有効な方法です。ただしヒープサイズに比例しGC時間が増加するため、ヒープサイズが大きいとGCにかかる時間はそれだけ長くなり、それに従ってアプリケーションの停止時間も長くなるため、レスポンスタイムに影響があります。






®ガーベッジ・コレクションの大容量ヒープへの対応～gencon

世代別GC(gencon)の登場（WAS v6.1～）

– 若いインスタンスと、時間を経たインスタンスを別々の領域に配置

– Nursery領域はさらに2つの領域に分割され、Copying方式

– Tenured領域にはConcurrent Mark & Sweep GC (CMS)方式

– メリット• 領域を分割するため、

大容量のヒープサイズでも効率よくGCの実行が可能

– デメリット• Nursery領域が小さいと頻繁にGCを繰

り返し、パフォーマンスに影響• Tenured領域でCompactionが発生する

と、GC時間が長くなる

SurvivorEden

Young（Nursery） Old（Tenured）

Survivor Eden

SurvivorEden

SurvivorEden

使用中

既存の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)でも対応できないような、さらに大容量のヒープサイズについて考慮が必要になりました。






®ガーベッジ・コレクションの大容量ヒープへの対応～balanced

バランスGC(balanced)の登場（WAS v8.0～）– 部分的ガーベッジ・コレクション（PGC)

• 同じサイズの領域に分割し、領域単位で管理• オブジェクトは空の領域に

割り当てられ、いっぱいになると、• 新しい空の領域に再編成

– グローバル・マーク・フェイズ（GMP）• PGCとは別にヒープ全体を管理

• 長時間使われていないオブジェクトをConcurrentにチェック

– バランスGCの制約• 64 ビット・プラットフォーム• 圧縮された参照が有効（-Xcompressedrefs）

– バランスGCの対象• 4GB以上のヒープサイズ

– メリット• 世代別GCでも対応が困難な

さらに大容量のヒープに対応• GCの影響範囲を抑えられる

– デメリット• チューニングが難しい

存続期間2

Eden（存続期間0） Eden（存続期間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の影響が大きく変わり、チューニングが難しいという面もあります。






®balanced GCの効果

同時アクセス数に対する平均/最大レスポンスタイムの測定例

負荷が高くなるほど差が顕著に現れる

Java Next Generation Garbage Collection （ Impact 2011 －Session Number: TAW-2303）より

上のグラフは、世代別GCとバランスGCを設定した環境での、同時アクセス数に対する平均/最大レスポンスタイムの測定例です。グラフより、同時アクセス数がそれほど多くなく、スレッド数も少ない時にはレスポンスタイムにあまり差はありませんが、同時アクセス数が多くなるとバランスGCを採用したほうがレスポンスタイムが良くなっていることがわかります。この結果より、大容量ヒープサイズを有する環境では、負荷が高くなるほどバランスGCのほうがレスポンスタイムがよくなる傾向があると言えるでしょう。






®

まとめ






®Java EE 6まとめ

開発がさらに容易なJava EE環境の実現

–プロファイル、プルーニングによる軽量化

–Webフラグメントに代表される拡張性

–アノテーションやCDIに示される、さらなるEase of Development–機能の大幅な強化

• Servlet 3.0やJSF 2.0によるプレゼンテーション層の強化

• JPA 2.0やBean Validationによる永続化の強化

大規模ヒープを考慮したJava環境へ–バランスGCなどに見られる、大規模ヒープを意識した新機能

当セッションのまとめは以上のようになります。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環境へと進化、発展を遂げています。






®参考文献

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_bailey.html

• http://www.ibm.com/developerworks/websphere/techjournal/1108_sciampacone/1108_sciampacone.html

websphere application server v8public.dhe.ibm.com/.../was_v8_ann_07_javaee6_part1.pdf– bean...

Documents