Java EE 5 / Java SE 6 1 日本IBMシステムズ・エンジニアリング(株) Webインフラストラクチャー

Java EE 5 / Java SE 6
日本IBMシステムズ・エンジニアリング(株)
Webインフラストラクチャー
植田 佳明 ([email protected])
© 2008 IBM Corporation
1
Disclaimer
WAS
WAS V7
V7 W/S
W/S
当資料で提供する技術情報は、各製品の出荷前コードに基づくものを含みます。
この資料は日本アイ・ビー・エム株式会社ならびに
日本アイ・ビー・エム システムズ・エンジニアリング株式会社の正式なレ
ビューを受けておりません。
当資料は、資料内で説明されている製品の仕様を保証するものではありません。
資料の内容には正確を期するよう注意しておりますが、この資料の内容は2008年
10月現在の情報であり、製品の新しいリリース、PTFなどによって動作、仕様が変
わる可能性があるのでご注意下さい。
今後国内で提供されるリリース情報は、対応する発表レターなどでご確認くださ
い。
WebSphere Application Server V7
Announcement Workshop 2008
#2
© IBM Corporation.
2
Agenda
WAS
WAS V7
V7 W/S
W/S
概要
EJB3.0
JPA (Java Persistence API)
WAS V7でのEJB3.0
Java SE 6
WebSphere Application Server V7
Announcement Workshop 2008
#3
© IBM Corporation.
3
概要
WebSphere Application Server V7
Announcement Workshop 2008
WAS
WAS V7
V7 W/S
W/S
#4
© IBM Corporation.
4
Enterprise Javaの歴史
WAS
WAS V7
V7 W/S
W/S
2008
Spring
Hibernate
SDO
Portlets
SCA
2006
BPEL
2003
2001
2000
1998
EJB 1.0
Servlet 2.1
J2EE 1.2
• EJB
• Servlet
• JSP
• JMS
• JavaMail
J2EE 1.3
• EJB
local EJBs
abs. CMP
MDB
• Servlet 2.3
Events
Filters
• JSP
XML
• JAXP
• Connectors
• JAAS
J2EE 1.4
• EJB 2.1
timers
pluggable JMS
• Web Services
Basic SOAP/HTTP
Registry
• JMX Mgmt
• J2EE Deployment
• JACC
Java EE 6
策定中
Java EE 5
• EJB 3
POJO components
POJO persistence
• Web Services
POJO components
protocol independence
JAXB
StAX
• JSF
• JSP
common EL
• Annotations
IoC
Ease of Development
WebSphere Application Server V7
Announcement Workshop 2008
#5
© IBM Corporation.
Java EEとはJava Platform, Enterprise Editionの略でJava言語でエンタープライズ向けアプ
リケーションを構築するためのフレームワーク・APIの総称です。
1999年に初めてJ2EE1.2として策定され、それから1.3、1.4とバージョンアップを重ねてきまし
た。ただ、仕様が複雑で実装も煩雑になる傾向があり（特にEJB）、そのアンチテーゼとして、
SpringやHibernateといった軽量なオープンソースフレームワークが登場してきました。Java EE
5ではそのオープンソースの良い面を取り入れるかたちで、Ease of Development (開発容易
性)ということをキーワードに仕様が策定されています。なお、1.4まではJ2EEと呼ばれていました
が、5.0からはバージョン表記を明確にする目的でJ2EE1.5ではなく、Java EE 5と呼ばれていま
す。
5
WASがサポートするJ2EE
WAS
WAS V7
V7 W/S
W/S
WAS
出荷開始年月(GA)
J2SE
J2EE
7.0
2008/09
Java SE 6
Java EE 5
6.1
2006/06
5.0
1.4
6.0
2004/12
1.4
1.4
5.1
2004/01
1.4
1.3
5.0
2003/01
1.3
1.3
4.0
2001/06
1.3
1.2
3.5
2000/08
1.2
N/A
WebSphere Application Server V7
Announcement Workshop 2008
#6
© IBM Corporation.
各WASのバージョンがサポートするJ2EEのバージョンは上記の表のようになります。Java EE
5の前提のJava SEは5ですが、WAS V7ではJava SE 6を採用しています。J2SEのバージョン
表記も5.0からはJ2SE1.5ではなく、Java SE 5となっています。
6
J2EE 1.4と比較して・・・
WAS
WAS V7
V7 W/S
W/S
Java EE 5 のメインテーマはEoD(開発容易性)
コンポーネントをPOJOとして実装
EJB2.xまでのような開発時の複雑な手続きを省くことを目的としている
アノテーションの使用
コーディング記述量の減少
インターフェースやデプロイメント記述子などの作成物の減少
オープンソースフレームワークによる影響
DI(Dependency Injection)、AOP(Aspect Oriented Programming)
O/Rマッピング
仕様面では以下のような大きな変更がある
EJB3.0
JPA (Java Persistence API)
Webサービス
など
WebSphere Application Server V7
Announcement Workshop 2008
#7
© IBM Corporation.
Java EE 5ではEoD (Ease of Development、開発容易性)というものをキーワードに仕様策定
されており、なるべく開発者にとっての負荷を軽減する工夫が取り入れられています。
そのための工夫として、まず開発コンポーネントをPOJO (Plain Old Java Object) として作成
できることを目的の一つとしています。POJOとは、もともとはMartin Fowler氏らがEJBを批判す
るために使い始めた言葉で、通常のJavaオブジェクトを意味します。つまり特別なインター
フェース実装やクラス継承といった煩雑なお作法を省く形でコーディングすることが可能になっ
ています。また、さまざまな場面でアノテーションを使った記述方法がサポートされており、コー
ディング量の減少や、デプロイメント記述子への設定省略などにつながっています。
Java EE 5は人気を博しているオープンソースフレームワークから大きな影響を受けています。
Spring、HibernateといったオープンソースフレームワークからDI、AOP、O/Rマッピング方式を
その仕様内に取り込んでいます。
実際の仕様面での大きな変更としては、EJBとWebサービスがあげられます。Webサービスに
ついては後続のセッションで詳細を述べることとし、本セッションでは主にEJB3.0 / JPAを中心
にとりあげます。
7
POJOって何だ
POJO = Plain Old Java Object
WAS
WAS V7
V7 W/S
W/S
直訳すると「何の変哲もない古きJavaオブジェクト」
仕様があるわけではないので、正式な定義はないが
Wikipediaより
あるJavaオブジェクトがEJB(特にEJB
あるJavaオブジェクトがEJB(特にEJB3より前のEJB)のように特殊なものではなく、ごく普通の
3より前のEJB)のように特殊なものではなく、ごく普通の
Javaオブジェクトであることを強調した名称。設計はシンプルであればあるほど良いと主張する人
Javaオブジェクトであることを強調した名称。設計はシンプルであればあるほど良いと主張する人
たちが好んで使用する。
たちが好んで使用する。
Contextual
Contextualvariations
variations
As
AsofofNovember
November2005,
2005,the
theterm
term"POJO"
"POJO"isismainly
mainlyused
usedtotodenote
denoteaaJava
Javaobject
objectwhich
whichdoes
does
not
follow
any
of
the
(major)
Java
object
models,
conventions,
or
frameworks
not follow any of the (major) Java object models, conventions, or frameworkssuch
suchas
as
EJB.
EJB.
All
AllJava
Javaobjects
objectsare
arePOJOs,
POJOs,therefore
thereforeideally
ideallyspeaking
speakingaaPOJO
POJOisisaaJava
Javaobject
objectnot
notbound
bound
by
any
restriction
other
than
those
forced
by
the
Java
Language
Specification.
by any restriction other than those forced by the Java Language Specification.I.e.,
I.e.,aa
POJO
POJOshould
shouldnot
nothave
havetoto
1.1.Extend
prespecified
Extend prespecifiedclasses
classes
2.2.Implement
Implementprespecified
prespecifiedinterfaces
interfaces
3.3.Contain
Containprespecified
prespecifiedannotations
annotations
EJB 3.0はアノテーションを使用しているので、「POJO likeな」と言ったほうが正確かもしれません
WebSphere Application Server V7
Announcement Workshop 2008
#8
© IBM Corporation.
前項で、Java EE 5はPOJOをベースとしたコンポーネントモデルを目標としているというお話
をしましたが、「POJO」とは、何でしょうか。POJO (Plain Old Java Object) は、仕様等があって
明確に定義されているわけではありません。もともとは、以前のEJBではないJavaオブジェクトの
ことを強調する言葉として用いられてきました。Wikipedia上でも、文脈によって使い方に相違が
ある言葉として認識位置づけられており、特別なクラスやインターフェースの拡張や実装と、アノ
テーションを含まないと言われています。例えば、EJB 3.0 の開発コンポーネントはアノテーショ
ンを含みますので、「POJO likeな」と言ったほうが正確かもしれません。
ただ、POJOか否かという議論ではなく、簡単に、誤りの無い、コードが書けて、簡単にテストで
きると言うことが重要です。
8
アノテーションとは
WAS
WAS V7
V7 W/S
W/S
ソースコード中でクラス、フィールドなどに対して属性情報を付加
Java SE 5.0で仕様追加
「@」記号で指定
コンテナーがアノテーションを認識して動作
クラス継承やインターフェース実装といったプログラミングのお作法を省略
デプロイメント・ディスクリプターの記述を代替
例 - EJB2.1とEJB3.0でのコーディング比較
EJB3.0ではアノテーションの使用により、お作法的なコーディングが省略される
EJB 2.1
public
publicclass
classCartBean
CartBean
implements
implementsSessionBean
SessionBean{{
private
SessionContext
private 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){{}}
EJB 3.0(アノテーション使用)
@Stateful
@Stateful
public
class CartBean implements
public
class CartBean
implements
ShoppingCart
{
ShoppingCart {
public int someShoppingMethod() { ... }
public int someShoppingMethod() { ... }
}
}
WebSphere Application Server V7
Announcement Workshop 2008
#9
© IBM Corporation.
アノテーションとは、ソースコード中にクラスやメソッドの属性情報を付加する機能です。概念自
体は以前からありましたが、J2SEの文法としてはJ2SE5.0から導入されました。
アノテーションとして記述された属性情報は、コンパイル後もクラスファイル中に残り、それを解釈
するツール（EJBであればコンパイラやEJBコンテナー）と組み合わされ機能を発揮します。
例では、CartBeanクラスについて@StatefulというEJB3.0用のアノテーションを指定していま
す。これをEJBコンテナー上で動かすとコンテナーはStateful Session Beanとして動作させま
す。EJB 2.1までは、特定のインターフェースを実装して、使用する必要のないメソッドもかなら
ずコード中に記述する必要があったため、比較してみるとよりシンプルなコーディングが可能に
なっていることがわかります。
WAS V7 InfoCenter - EJB 3.0 metadata annotations
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.webspher
e.nd.doc/info/ae/ae/rejb_3annotations.html
9
DIとは
WAS
WAS V7
V7 W/S
W/S
DI (Dependency injection) とは
制御の逆転
クライアントがサービスを呼び出すのではなく、コンテナが実行時にサー
ビスを注入
DIの効果
サービスの柔軟性向上
テスト容易性向上
Java EE 5ではアノテーションを利用してDIを実現
EJB 2.1
Object
Objectobj
obj==
Context.lookup(“java:comp/env/ejb/MyCartHome”);
Context.lookup(“java:comp/env/ejb/MyCartHome”);
CartHome
CartHometheCartHome
theCartHome==(CartHome)
(CartHome)
PortableRemoteObject.narrow(obj,
PortableRemoteObject.narrow(obj,CartHome.class);
CartHome.class);
ShoppingCart
myCart
=
theCartHome.create()
ShoppingCart myCart = theCartHome.create();;
myCart.someShoppingMethod();
myCart.someShoppingMethod();
EJB 3.0
@EJB
@EJB
private
privateShoppingCart
ShoppingCart myCart;
myCart;
public
void
someMethod()
{{
public
void
someMethod()
myCart.someShoppingMethod();
}} myCart.someShoppingMethod();
WebSphere Application Server V7
Announcement Workshop 2008
# 10
© IBM Corporation.
DI (Dependency Injection) の技術はオープンソースフレームワークのSpringなどが最初に導
入した技術です。これは例えばクライアントから使用するオブジェクトを取得する代わりに、実行
時に、必要なオブジェクトをコンテナから注入してもらうという方法をとります。Java EE 5ではアノ
テーションを使用してDIを実現しています。これによってクライアント側はサーバー側の実装に
依存せずに開発を行うことができます。インターフェースさえ定義・遵守されれば、柔軟にサー
バー実装を置き換えることができるようになります。また、テストのときには、Mockオブジェクトを
使用することで、JNDI非依存で簡単にテストを行うことが可能になります。
DIを使用するとコーディングの量も削減されますが、テスト容易性も大きく向上します。
10
EJB3.0
WebSphere Application Server V7
Announcement Workshop 2008
WAS
WAS V7
V7 W/S
W/S
# 11
© IBM Corporation.
11
EJB (Enterprise Java beans) とは
WAS
WAS V7
V7 W/S
W/S
Java EEアプリケーションのビジネスロジック層を担当
ビジネスロジック実装のフレームワークを提供
EJBプログラム（コンポーネント）とコンテナ（フレームワーク）の処
理分担
コンテナはトランザクション管理などの機能を提供
開発者はビジネスロジックを実装するコンポーネントのみを開発
分散環境で利用できる仕組みを提供
Java EEアプリケーション
Webコンテナ
クライアント
ブラウザ
JSP
EJBコンテナ
EJB
DB
Servlet
プレゼンテーション層
ビジネスロジック層
WebSphere Application Server V7
Announcement Workshop 2008
# 12
© IBM Corporation.
EJBはJava EE アプリケーションのビジネスロジック部分を実装するためのフレームワークです。
開発者ビジネスロジックを実装したコンポーネントのみを開発し、EJBコンテナという実行環境上
でその開発コンポーネントを動作させます。EJBコンテナはトランザクション管理など様々な機能
を提供し、EJBコンポーネントはコンテナーの機能を使用します。こういった開発スタイルのため、
開発者はビジネスロジックの実装にのみ注力できます。
また、EJBの大きな特徴としては分散環境での実行を可能にしている点です。これにより、より
柔軟なかたちでシステムを構成することができます。
12
EJB 2.x までは・・・
WAS
WAS V7
V7 W/S
W/S
さまざまな問題点が指摘されていた
EJBを作るのが難しい
本質的なビジネス・ロジックとは関係ない作成物、実装コードが多
い
継承、実装のお作法、APIが複雑
EJB クライアントもコーディングのお作法が複雑
ユニットテストが困難
・・・・・などなど
EJBのアンチテーゼとしてオープンソースフレームワークが台頭
軽量で開発が容易
DI (Dependency Injection)コンテナー、軽量コンテナー
Spring、Seasar2など
O/Rマッピング・フレームワーク
Hibernate、iBATISなど
WebSphere Application Server V7
Announcement Workshop 2008
# 13
© IBM Corporation.
ただし、J2EEのコンポーネントであるServletやJSPが広く普及しているのに対して、EJBはそ
れほど広くは普及していません。
これにはさまざまな原因が考えられ、以下のような問題点が指摘されていました。
まず、EJBは作成手順やAPIが複雑なため開発に手間がかかってしまうという点が挙げられま
す。また、手間をかけて開発したところで、実行してみるとその処理負荷が高く、処理が遅いとい
う点もEJBが普及しない原因といえます。その他にも、アプリケーション・サーバー上でしか動作
しないのでユニットテストが困難である、開発者が作成したコードと自動生成されたコードの関係
が見えにくい、などEJBの普及を妨げるさまざまな要素が挙げられます。
それに対してのアンチテーゼとしてオープンソースフレームワークが台頭してきました。オープ
ンソースフレームワークはビジネスロジック実装にあたってEJBと比較すると軽量で、かつ開発も
しやすく、DIなどアプリケーション全体のアーキテクチャーを考える上でも有利な機能を備えてい
ました。
こういった背景の下、EJB 3.0が登場します。
13
EJB 3.0 の3つのドキュメント
WAS
WAS V7
V7 W/S
W/S
EJB 3.0の仕様
EJB Core Contracts and Requirements
EJBコンテナの実装関連
EJB 3.0 Simplified API
Session/Message Driven BeanのAPI仕様
Java Persistence API
新しい永続化仕様(これまでのEntity Beanに相当)
Entity Classの詳細
WebSphere Application Server V7
Announcement Workshop 2008
# 14
© IBM Corporation.
EJB 3.0は、Java EE 5のメインコンポーネントの1つです。 Java EE 5のベースとなるのは
J2SE 5です。
EJB3.0の仕様書は、Persistence API、EJB3.0 Simplified API、EJB Core Contracts and
Requirementsの3つから構成されています。
EJB Core Contracts and Requirementsでは、EJBコンテナの実装関連について記述されて
おり、アプリケーション開発者よりもJ2EEアプリケーション・サーバーなどといった実行環境の開
発ベンダー向けの仕様書になります。
EJB 3.0 Simplified APIでは、EJBの全体的な仕様やSession Bean、Message Driven
BeanなどといったEntity Bean以外の仕様について記述されています。
Persistence APIでは、新しい永続化仕様であるEntity Classに関する内容が記述されていま
す。
「JSR-000220 Enterprise JavaBeans 3.0 (Final Release)」
http://jcp.org/aboutJava/communityprocess/final/jsr220/index.html
14
EJB 3.0仕様の特徴
WAS
WAS V7
V7 W/S
W/S
純粋なビジネスロジック作成のためのフレームワークへ
仕様において必ずしも分散環境を前提とはしないビジネスアプリケー
ションフレームワークであることをうたっている
EJB2.1で想定していた「分散環境」の枠組みを取り払う
開発容易性
アプリケーション開発者からみた複雑性の排除
JPA (Java Persistence API) の独立
EJB2.1ではEntity BeanとしてEJBの一種として定義されていた
EJB3.0では他のEJBから独立する形で仕様が定義されている
JPA単体でJava SE環境での利用も想定されている
WebSphere Application Server V7
Announcement Workshop 2008
# 15
© IBM Corporation.
EJB 3.0 の仕様では、下記のようにEJBの目的が記述されています。EJB 2.1 の仕様では、1
番目と2番目の項目が、「distributed object-oriented」のように合わせて記述されていたものが、
2つの項目に分割されました。これは、必ずしも分散コンポーネントのみに特化するわけではなく、
ビジネス・ロジックのコンポーネントのフレームワークを提供を目指していることを表しています。
また、後述しますが、EJB 3.0 の主要なアップデートは、アプリケーション開発者の観点からの複
雑性の排除です。
EJB 3.0 (JSR 220: Enterprise JavaBeans,Version 3.0 - EJB Core Contracts and
Requirements) 仕様より
-----------------------------------------------------------The Enterprise JavaBeans (EJB) architecture has the following goals:
• The Enterprise JavaBeans architecture will be the standard component
architecture for building object-oriented business applications in the Java
programming language.
• The Enterprise JavaBeans architecture will be the standard component
architecture for building distributed business applications in the Java
programming language.
-----------------------------------------------------------(参考) EJB 2.1 の仕様でこの2項目にあたる記述
The Enterprise JavaBeans architecture will be the standard component architecture for
building distributed object-oriented business applications in the Java programming
language.
15
EJB の種類
Session Bean, Message Driven Bean
の基本機能は変わらず、EJB 3.0では、
Ease of Developmentを実現
Session Bean
WAS
WAS V7
V7 W/S
W/S
ビジネスロジックを実装
StatelessとStatefulの2つのセッションObject
Message Driven Bean
MOMのキューからメッセージを取り出して、非同期にビジネスロ
ジックを実行
Message
Queue
Entity
EJB 3.0では、JPAで定義されるEntity ClassとEntity Objectに
必ずしもEJBコンテナー上ではなく、J2SE上でも稼動可能
データを永続的に保存するJava Beans
DB
EJB3.0の機能的なアップデートのメインは
JPA (Entity Object)
WebSphere Application Server V7
Announcement Workshop 2008
# 16
© IBM Corporation.
EJBの種類には、上記のように3種類のEJBがあります。EJB 3.0 では、Session Beanと
Message Driven Beanは、これまでと同様の機能を持ちつつ、Ease of Developmentが実現さ
れました。
また、EJB 3.0では、以前のEntity Beanは、JPAという形で新たに仕様が定義され、O/Rマッピ
ングは大きく機能が向上し、開発容易性も大きく向上しています。
16
EJB 3.0 Session Bean
WAS
WAS V7
V7 W/S
W/S
Session Beanはビジネスロジックを実装
BeanクラスとBusinessインターフェースから構成される
Beanクラスにビジネスロジックを記述
Beanクラスは必ず一つのBusinessインターフェースを実装する必要がある
Businessインターフェースは特別なインターフェース継承や例外スローを必要と
しない通常のJavaインターフェース
Businessインターフェースにはクライアントに公開するBeanクラス内のメソッド
を記述
クライアントはBusinessインターフェース経由でメソッドを実行
EJBコンテナ
Webコンテナ
Bean Class
Servlet
EJB3CllientServlet
クラス
OrderTaskインター
フェースを通じて
getCustomer()メソッド
を呼び出す
Business Interface
OrderTask
インターフェース
OrderTaskImpl
クラス
getCustomer（）
メソッド
実装
WebSphere Application Server V7
Announcement Workshop 2008
# 17
© IBM Corporation.
ここからはSession Beanをとりあげます。
Session BeanとはEJB3.0の仕様で定義されるEJBの一種で、ビジネスロジックを実装します。
クライアントはリモート(別JVM)あるいはローカル(同一JVM)からその実装した機能を使用するこ
とが可能です。
EJB 3.0ではSession Beanを開発する際には実際にビジネスロジックを記述するBeanクラスと
Beanクラスによって実装されるBusinessインターフェースを作成する必要があります。クライアン
トはBusinessインターフェース経由でロジックを実行します。Businessインターフェースは特別
なインターフェースを実装、継承する必要はなく、通常のJavaインターフェースです。
17
EJB 2.xまでのSession Bean
WAS
WAS V7
V7 W/S
W/S
Beanクラスは2つのインターフェースを実装しなければならない
Homeインターフェース
Session Beanの生成、破棄などのライフサイクルを管理
RemoteインターフェースまたはLocalインターフェース
クライアントに公開するメソッドを記述
クライアントのからのアクセス方式に応じてどちらかのインターフェースを実装
実装上のお作法が複雑
特定のインターフェース継承、実装や例外のスローが必要
EJBコンテナ
Webコンテナ
Home Interface
Servlet
Beanインスタンス生成
OrderTasｋ取得
EJB3CllientServlet
クラス
OrderTaskインター
フェースを通じて
getCustomer()メソッド
を呼び出す
Bean Class
OrderTaskHome OrderTaskImpl
インターフェース
クラス
OrderTask
インターフェース
getCustomer（）
メソッド
Remote Interface
WebSphere Application Server V7
Announcement Workshop 2008
# 18
© IBM Corporation.
EJB3.0と2.xを比較してみます。
EJB3.0ではインターフェースは一つでよかったのと比較して、EJB2.xではBeanクラスはHome
インターフェースというBeanインスタンスのライフサイクル管理を定義したインターフェースと実際
にビジネスロジックを記述したRemote (またはLocal) インターフェースの2種類を実装する必要
がありました。その結果、仕組みとしても非常に理解しずらいものとなっていました。
さらに各インターフェースは決まったインターフェースを実装したり、例外のスローが必要で
あったりと、煩雑なコーディングを強いられる傾向にあり、EJBが敬遠される理由のひとつにも
なっていました。
18
コーディング比較(Beanクラス & インターフェース)
WAS
WAS V7
V7 W/S
W/S
3.0ではBusinessインターフェースのみ
Homeインターフェースは必要なし
アノテーションの活用でお作法的なコーディングが簡単に
@Remote、@Local (Businessインターフェース)
@Stateless、@Stateful (Beanクラス)
3.0 Code
2.1 Code
public interface ShoppingCartHome
public interface ShoppingCartHome
extends EJBHome {
extends EJBHome {
ShoppingCart create()
ShoppingCart create()
throws RemoteException,
throws RemoteException,
CreateException;
CreateException;
}
}
Home Interface
public interface ShoppingCart
public interface ShoppingCart
extends EJBObject {
extends EJBObject {
public int someShoppingMethod()
public int someShoppingMethod()
throws RemoteException;
throws RemoteException;
}
}
public class CartBean
public class CartBean
implements SessionBean {
implements SessionBean {
private SessionContext ctx;
private SessionContext ctx;
public int someShoppingMethod() { … }
public int someShoppingMethod() { … }
public void ejbCreate() { }
public void ejbCreate() { }
public void ejbRemove() { }
public void ejbRemove() { }
public void ejbActivate() { }
public void ejbActivate() { }
public void ejbPassivate() { }
public void ejbPassivate() { }
public void setSessionContext
public void setSessionContext
(SessionContext ctx) { }
(SessionContext ctx) { }
}
}
Remote Interface
@Remote
@Remote
public interface ShoppingCart {
public interface ShoppingCart {
public int someShoppingMethod();
public int someShoppingMethod();
}
}
Business Interface
@Stateful
@Stateful
public
class CartBean implements
public
class CartBean
implements
ShoppingCart
{
ShoppingCart {
public int someShoppingMethod() { ... }
public int someShoppingMethod() { ... }
}
}
Enterprise Bean Class
Enterprise Bean Class
WebSphere Application Server V7
Announcement Workshop 2008
# 19
© IBM Corporation.
こちらはコーディングの比較です。
上記の例からも分かりますように、EJB 3.0 では、特別なお作法に惑わされること無く、ビジネ
スロジックを実装しているクラスの作成と、その公開メソッドをそのままインターフェースとして公開
するという非常に素直なコーディングになっています。
また、EJBであることは、アノテーション(@Remoteや@Stateless)を使用して示し、EJB固有
のクラスやインターフェースの継承や実装は必要ありません。
19
コーディング比較(クライアント)
WAS
WAS V7
V7 W/S
W/S
EJB 3.0では
DIを利用してBusinessインターフェースのインスタンスを取得
@EJBアノテーションを利用
JNDIによるlookupも従来どおり利用可能
AppServer
AppServer
JNDI
lookup()
クライ
アント
create()
(or lookup() )
EJBコンテナ
EJBHome
EJBObject
Enterprise
Bean
EJBコンテナ
クライ
アント
目的のメソッド
2.x
2.x Code
Code
Object obj = Context.lookup(“java:comp/env/ejb/MyCartHome”);
Object obj
= Context.lookup(“java:comp/env/ejb/MyCartHome”);
CartHome
theCartHome
= (CartHome)
CartHome
theCartHome = (CartHome) CartHome.class);
PortableRemoteObject.narrow(obj,
PortableRemoteObject.narrow(obj,
CartHome.class);
ShoppingCart myCart = theCartHome.create()
;
ShoppingCart myCart = theCartHome.create() ;
myCart.someShoppingMethod();
myCart.someShoppingMethod();
JNDI
@EJB
Business
Interface
Enterprise
Bean
目的のメソッド
3.0
3.0 Code
Code
@EJB
@EJB ShoppingCart myCart;
private
private ShoppingCart myCart;
public void someMethod() {
public
void someMethod() {
myCart.someShoppingMethod();
myCart.someShoppingMethod();
}
}
WebSphere Application Server V7
Announcement Workshop 2008
# 20
© IBM Corporation.
一方、こちらはクライアント側のコーディング比較です。
EJB 3.0 では、これまでのEJB 2.x のときは、クライアント側のコーディングも変わり、Homeオ
ブジェクトをlookupする必要はありません。直接、Businessインターフェースを実装したインスタ
ンスを取得し、そのメソッドが実行できます。また、Businessインターフェースを実装したインスタ
ンスの取得方法も、コード上でlookupする方法だけでなく、アノテーションを使用したDIで取得
することができます。これにより、非常にシンプルなコーディングでEJB呼び出しを行うことができ
ます。また、アノテーションを使用したDIを利用することにより、EJBサーバー側が完成していなく
ても、簡単にモックオブジェクトを作成・登録できますので、EJBクライアント側のテストも容易に
行うことができます。
20
EJB3.0におけるMessage Driven Bean
WAS
WAS V7
V7 W/S
W/S
アノテーションベースでのコーディングが可能
@MessageDriven
アクティベーション・スペックの設定が可能
@MessageDrivenでMDBであることを宣言
@MessageDriven(
アクティベーション・スペックの設定
name="CreateUsersCardJMSProcessor",
messageListenerInterface="javax.jms.MessageListener"
activationConfig= {
@ActivationConfigProperty(
propertyName="destinationType",
propertyValue="javax.jms.Queue"),
@ActivationConfigProperty(
propertyName="destinationName"
propertyValue="jms/CreateUsersRequestQueue")
})
public class CreateUsersCardProcessor{
public void onMessage(javax.jms.Message msg) {
}
}
onMessageメソッド
WebSphere Application Server V7
Announcement Workshop 2008
# 21
© IBM Corporation.
次にEJB3.0でのMessage Driven Bean (MDB) です。
機能的にはEJB2.1からの変更点はほとんどありませんが、EoDの観点からアノテーションを使っ
て、より容易にコーディングすることが可能になっています。
コーディング例では@MessageDrivenというアノテーションを使用しています。
@MessageDrivenアノテーションがあることによってEJBコンテナはこのコンポーネントをMDBと
して取り扱います。
21
トランザクション
WAS
WAS V7
V7 W/S
W/S
EJBのトランザクション実装は管理する主体に応じて2種類存在
CMT(Container Managed Transaction)：コンテナー管理
BMT(Bean Managed Transaction)：Bean管理(コーディングでトラ
ンザクションを制御)
CMTかBMTかはアノテーションによって指定可能
@TransactionManagementTypeアノテーション
CMTの場合、メソッドごとのトランザクション属性もアノテー
ションで指定できる（@TransactionAttributeアノテーションの
利用）
コンテナー管理のトランザクション
@Stateless
@TransactionManagement(TransactionManagementType.CONTAINER)
@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
public class EJB3BankBean implements EJB3BankService {
・・・省略・・・
@TransactionAttribute(TransactionAttributeType.REQUIRED)
トランザクション属性は
NOT_SUPPORTED
public Customer getCustomer(String ssn) throws ITSOBankException
{
・・・省略・・・
}
}
WebSphere Application Server V7
Announcement Workshop 2008
# 22
© IBM Corporation.
トランザクションについてもMDBと同じく、EJB2.1から機能的な変更はありませんが、こちらもア
ノテーションを使ってトランザクション機能を利用できるようになっています。
上記はStateless Session Bean内でトランザクションを使用するときのコーディング例です。
@TransactionManagementや@TransactionAttributeアノテーションを使用することにより、トラ
ンザクション管理方法や属性がソースコード内に記述できます。これにより、デプロイメント記述
子への設定を省略することが可能になります。
22
EJB 3.0での新機能 – Interceptor (1/2)
WAS
WAS V7
V7 W/S
W/S
EJB3.0ではAOP(Aspect Oriented Programming) を実現するためにInterceptorと
呼ばれる機能を提供している
AOP (Aspect Oriented Programming)とは
AOPは横断的関心事をクラスの定義から分離し、必要に応じて挿入するという形
をとる
横断的関心事とは中心となるビジネスロジック以外の処理(ロギング、トランザ
クション制御など)で、複数のモジュールに散在するものを言う。
メリット
本質的なビジネスロジック部分の開発を分離できる
ログ処理などの再利用性、変更への耐性が高まる
モジュールA
ログ処理が
散在
モジュールB
モジュールA
AOP
モジュールB
WebSphere Application Server V7
Announcement Workshop 2008
ログ処理
# 23
© IBM Corporation.
EJB3.0の新機能の一つにInterceptorというものがあります。これはAOP (Aspect Oriented
Programming) を可能にする仕組みです。
クラス定義の中には本質的な役割ではなく、複数のクラスに必要とされる役割が入りこんでしま
うことがあります。ロギング処理や、トランザクション中のデータベース接続処理などが代表的で
す。この役割は、「横断的な関心事」と呼ばれます。
AOPとは、この「横断的な関心事」を分離して、各クラスには本質的な役割のみを記述し、必要
に応じて「横断的な関心事」の結びつけを行なうプログラミング方式です。
・AOP指向プログラミングのメリット
クラス定義にはオブジェクトの本質的な役割のみ記述される為、プログラミングがシンプルになり
ます。
横断的な関心毎が分離され纏めて管理出来る為、再利用性・変更への耐性が高まります。
23
EJB 3.0での新機能 – Interceptor (2/2)
WAS
WAS V7
V7 W/S
W/S
Interceptorの利用
Interceptorは一つのクラスとして作成する
EJBのメソッド呼び出し時に割り込み、前後に追加ロジックを埋め込む
前処理、EJBメソッド実行、後処理はInterceptorクラス内に記述
Session BeanまたはMessage Driven Beanで使用可能
getCustomer()
メソッドの呼び出し
EJB3CllientServlet
クラス
Audit1（）結果
getCustomer（）結果
Audit2（）結果
Audit1()、Audit2()
メソッドを前後に挟む
AuditInterceptor
クラス
Audit1（）
インターセプト対
象メソッド実行
OrderTaskImpl
クラス
getCustomer（）
メソッド
Audit2（）
WebSphere Application Server V7
Announcement Workshop 2008
# 24
© IBM Corporation.
EJB3.0ではAOPをInterceptorと呼ばれる実装で実現しています。ログ処理などのAOPの横
断的関心事はInterceptorに記述します。実行時にはクライアントからのメソッド呼び出しを
Interceptorが横取りをする形で処理を挟み込みます。この機能はSession BeanかMessage
Driven Beanでのみ使用可能です。
24
(参考)Interceptorコーディング例
WAS
WAS V7
V7 W/S
W/S
Interceptorクラス
public class AuditInterceptor {
@AroundInvoke
public Object audit(InvocationContext invocationContext) throws Exception
{
まずこのメソッドが実行される
・・・・省略・・・
System.out.println("Customer Id " + param[0] + " executing operation -> " +
name);
return invocationContext.proceed();
}
}
Interceptorされるクラス
Proceed()によってインターセプト
対象のメソッドが実行される
@Stateless
@Interceptors(AuditInterceptor.class)
public class OrderTaskImpl implements OrderTask {
・・・・省略・・・
public Order getCurrentOrder(int customerId) throws CustomerDoesNotExist {
・・・省略・・・
return currentOrder;
}
}
WebSphere Application Server V7
Announcement Workshop 2008
# 25
© IBM Corporation.
Interceptorのコーディング例です。
25
JPA (Java Persistence API)
WebSphere Application Server V7
Announcement Workshop 2008
WAS
WAS V7
V7 W/S
W/S
# 26
© IBM Corporation.
26
JPA登場 の背景
WAS
WAS V7
V7 W/S
W/S
EJB 2.1 でのパーシスタンスの課題
複雑なプログラミング・モデル
Entity Beanは「重過ぎる」
EJBQL は制限が多い (機能的に不足)
対策として他のアプローチの出現
カスタム・フレームワークまたは「素の」 JDBC
オープンソースフレームワークのO/Rマッピング ソリューション
Toplink (現在の EclipseLink)
Hibernate
など
EJB3.0仕様はオープンソースフレームワークのO/Rマッピング方式を選択
WebSphere Application Server V7
Announcement Workshop 2008
# 27
© IBM Corporation.
EJB2.1ではEntity BeanがJavaとRDBを仲介するものとして定義されていました。しかし、
Entity Beanは複雑であるとか、処理が重たい、EJBQLの機能不足など、さまざまな問題点が指
摘されていました。
一方、オープンソースフレームワークの世界ではHibernate、ToplinkなどのO/Rマッピングフ
レームワークが登場し、その使いやすさから様々なところで使われるようになってきました。
EJB3.0ではJPA (Java Persistence API)がEntity Beanにとって変わりましたが、このJPAは
オープンソースフレームワークで実績のあるO/Rマッピング方式をとりいれています。
27
O/Rマッピング概要
WAS
WAS V7
V7 W/S
W/S
O/Rマッピング
オブジェクトとリレーショナル(主にRDBレコード)の間にある差異を吸収して
リレーショナルに格納されているデータをオブジェクトとして直感的に扱いや
すくするための仕組み
以下のようにマッピングされる
クラス⇔テーブル定義
フィールド⇔カラム
インスタンス化されたオブジェクト⇔レコード
支給日: 2007/01/25
支給額: 300000
名字: たなか
名前: よしお
支給日: 2007/01/25
支給額: 250000
社員テーブル
社員ID
名字
名前
126
たなか
よしお
743
すずき
はなこ
名字: すずき
名前: はなこ
手当てテーブル
支給日: 2007/02/10
支給額: 7000
手当てID
対象者ID
支給日
支給額
1
743
2007/1/25
300000
2
126
2007/1/25
250000
3
743
2007/2/10
7000
WebSphere Application Server V7
Announcement Workshop 2008
# 28
© IBM Corporation.
JPAの説明に入る前に、簡単にO/Rマッピングについて説明します。
システムにおけるデータ保管の方式として事実上の標準技術であるリレーショナル・データ
ベースですが、オブジェクトとリレーショナルでは情報の表現の仕方そのものが本質的に異なっ
ています。そのため、オブジェクト指向言語であるJavaでリレーショナルのデータを扱うには、
SQLを発行した結果得られる結果セットから必要な情報を取り出してオブジェクトに構築していく
という、データ表現の違いをコードのレベルで埋め合わせていく作業が必要になります。この、業
務のそのものの実装とは異なり、かつ面倒な作業の繰り返しの多い作業は開発効率を下げる要
因となります。そのためこの作業をツールによってある程度自動化できないか、という観点から出
てきたソリューションがO/Rマッピングです。
28
JPAとは
WAS
WAS V7
V7 W/S
W/S
Java Persistence API（JPA）とは
EJB3.0仕様の一部として策定(JSR220)
POJOベースで簡略化されたO/Rマッピング
javax.persistenceパッケージに定義されたAPI
Java Persistence Query Language (JPQL)
アノテーションでのコーディングが可能に
Java EE 5 または Java SEでの利用が可能
J2EEアプリケーション･サーバー外での利用も可能
WAS V7ではApache OpenJPAをもとにJPA実装がされている
JPA for WebSphere Application Server
機能拡張やユーティリティ追加がされている
wsjpaversionコマンドでOpenJPAのバージョン確認が可能
WebSphere Application Server V7
Announcement Workshop 2008
# 29
© IBM Corporation.
JPAとはEJB3.0で規定されたO/Rマッピングです。従来の（EJB2.1までの）Entity Beanの使
いにくさ・作りにくさ・分かりにくさという反省を踏まえ、POJOをベースにした簡略化されたコード
でのO/Rマッピングを実現しています。APIの定義にはJava Persistence Query Language
（JPQL）という操作言語と、O/Rマッピング用のメタデータ定義が含まれています。
これまでEJBの一種として定義されていたEntity Beanは、EJB3.0ではJPAとして独立した規
格となっています。つまり、JPAはJava EE環境（WASのようなアプリケーション･サーバー環境）
だけでなく、Java SE環境での使用も可能になっています。
また、WASではJPA実装として、Apache OpenJPAをベースに機能拡張やユーティリティ追
加を施したものを採用しています。
WAS V7 InfoCenter - Task overview: Storing and retrieving persistent data with the Java
Persistence API (JPA)
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.webspher
e.nd.doc/info/ae/ae/tejb_introjpa.html
29
JPA全体像
WAS
WAS V7
V7 W/S
W/S
EntityManager
Entity
Query
Entitiの操作
JPQL
select o from Order o・・・
クライアント･プログラム
getEmp_Id() emp_Id=111111
getName() name=Nakajima
@Entity
Employee
setEmp_Id()
setName()
getPhone() phone=1804-1111 setPhone()
@Id
getEmp_Id() emp_Id
getName() name
setEmp_Id()
phone
setPhone()
getPhone()
setName()
EMPLOYEE表
Persistence
Persistence Context
EMP_ID
NAME
PHONE
111111
Nakajima
1084-1111
222222
Hirabayashi
1804-2222
333333
Yamaguchi
1803-3333
WebSphere Application Server V7
Announcement Workshop 2008
# 30
© IBM Corporation.
JPAの全体像を俯瞰してみましょう。大きく分けて四つの概念をここでは覚えてください。
一つ目は、Entity（エンティティ）です。Entityは表にマップされたオブジェクトです。
二つ目はEntityManager（エンティティ･マネジャー）です。クライアントはEntityを使用するのに、
EntityManagerというインターフェースを介して検索・生成・削除といった操作を行います。
三つ目はPersistence Context（永続化コンテキスト）です。Persistence Contextは
EntityManagerと紐づくエンティティのインスタンスの集合を表します。
四つ目はQueryです。RDBに対してSQLで操作するのと同じ感覚でEntityを操作するために
使用するインターフェースがQueryです。
次のページから、それぞれの概念をもう少し詳しく解説します。
30
Entity
WAS
WAS V7
V7 W/S
W/S
Entityは「永続化可能なJavaオブジェクト」
具体的にはDBの表に相当するオブジェクト
通常のJavaクラス（POJO）に@Entityアノテーションを付与して作成
@Entity
Employeeクラス
インスタンス化・
レコードとの関連付け
emp_Id=111111
name=Nakajima
phone=1804-1111
@Entity
@Entity
アノテーション
アノテーション
EMPLOYEE表
@Id
emp_Id
name
phone
・・・
・・・
@Entity
@Entity
public
class
Employee
public class Employee implements
implements Serializable
Serializable {{
@Id
@Id
private
private int
int emp_Id;
emp_Id;
private
private String
String name;
name;
private
private String
String phone;
phone;
public
public int
int getEmp_Id()
getEmp_Id() {{
return
return this.emp_Id;
this.emp_Id;
}}
public
public void
void setEmp_Id(int
setEmp_Id(int emp_Id)
emp_Id) {{
this.emp_Id
this.emp_Id == emp_Id;
emp_Id;
}}
・・・
・・・
}}
EMP_ID
NAME
PHONE
111111
Nakajima
1084-1111
222222
Hirabayashi
1804-2222
333333
Yamaguchi
1803-3333
テーブルカラム
テーブルカラム
に対応する
に対応する
フィールド
フィールド
Employeeクラス
WebSphere Application Server V7
Announcement Workshop 2008
# 31
© IBM Corporation.
Entityとは「永続化可能なJavaオブジェクト」をさします。具体的にはRDBにある表に相当する
オブジェクトだと思ってください。データベースの表（テーブル）に列（カラム）があるように、Entity
には変数（フィールド）があります。またそれらのフィールドを操作するためのアクセッサー･メソッ
ド（getter/setter）があります。Entityをインスタンス化するということは、データベースの行に相当
するレコードをEntityのフィールドに関連付けることです。
Entityには旧来のEntity Beanのようにhomeインターフェースやlocalインターフェースを作る必
要はありません。通常のJavaクラスを作成し、クラスの頭に@Entityアノテーションを付与して作
成します。書かなくてはならないコードはEntity Beanに比べ格段に減り、またコードの可読性も
大幅に増しています。
ただし、Entityにはいくつかの制約事項があります。newするために引数なしのコンストラクタを
定義する必要がある点、主キーに相当するフィールドを持たなくてはならない点などです。
31
EntityManagerとPersistence Context
WAS
WAS V7
V7 W/S
W/S
EntityManager
Entityを操作するためにJPAが提供するインターフェース
javax.persistence.EntityManager
クライアント･プログラムはEntityManagerを介してEntityを操作
Persistence Conetxt
Entityインスタンスの集合
Persistence Contextの中でEntityManagerにより個々のEntityインスタンスの
ライフサイクルが管理される
EntityManager
クライアント･プログラム
EMPLOYEE表
PersistenceContext
employee
emp_Id=111111
employee
emp_Id=222222
DBへの永続化
インスタンス作成
EMP_ID
NAME
PHONE
111111
Nakajima
1084-1111
222222
Hirabayashi
1804-2222
333333
Yamaguchi
1803-3333
WebSphere Application Server V7
Announcement Workshop 2008
# 32
© IBM Corporation.
EntityManagerはEntityを操作するためのインターフェースです。従来のEntity Beanでは
homeインターフェースという操作用のインターフェースを各Entity Bean毎に定義していました
が、JPAでは共通のインターフェースが提供されるので個々のEntity用に作成する必要はありま
せん。
クライアント・プログラムはこのEntityManagerのメソッドを介してEntityの操作を行います。そう
することにより、Entityとデータベースとの関連付けがなされます。つまり、EntityManagerは
Entity操作用のfaçadeインターフェースと考えてください。
Persistence Contextは永続化コンテキストと訳されますが、名前からは今ひとつ何者であるか
イメージしづらいものです。Persistence Contextを一言で言うと、Entityのインスタンスの集合で
す。Persistence ContextはEntityManagerと関連付けられ、その中で個々のEntityインスタンス
のライフサイクルが管理されます。Persistence Contextは@PersistenceContextアノテーション
をEntityManager宣言の直前に入れる事で、EntityManagerとの関連付けが行われます。
32
(参考) EntityManager/Persistence Context 例
WAS
WAS V7
V7 W/S
W/S
クライアント・プログラム
package
package jpatest.sessions;
jpatest.sessions;
import
import java.util.List;
java.util.List;
import
import
import
import
import
import
javax.ejb.Stateless;
javax.ejb.Stateless;
javax.persistence.EntityManager;
javax.persistence.EntityManager;
javax.persistence.PersistenceContext;
javax.persistence.PersistenceContext;
import
import jpatest.entities.Employee;
jpatest.entities.Employee;
@Stateless
@Stateless
@PersistenceContextを指定して
@PersistenceContextを指定して
public
{{
public class
class EmployeeTaskImpl
EmployeeTaskImpl implements
implements EmployeeTask
EmployeeTask
EntityManagerを取得
EntityManagerを取得
@PersistenceContext
@PersistenceContext
EntityManager
EntityManager em;
em;
｝｝
public
public Employee
Employee findEmployee(int
findEmployee(int emp_Id)
emp_Id) {{
Employee
Employee employee
employee == (Employee)
(Employee) em.find(Employee.class,
em.find(Employee.class, emp_Id);
emp_Id);
return
return employee;
employee;
}}
EntityManagerのfindメソッドでEntityを取得
EntityManagerのfindメソッドでEntityを取得
WebSphere Application Server V7
Announcement Workshop 2008
# 33
© IBM Corporation.
このページの例は、先ほどのEmployeeというEntityを操作するクライアント･プログラム
（EmployeeTaskImpl）にあるEntityManagerおよびPersistence Contextの例です。
EmployeeTaskImplはStateless Session Beanです。クラス定義の中で
@PersisitenceContextアノテーションと共にEntityManagerが宣言され、そのEntityManagerイ
ンスタンス（em）のfind()メソッドを使用してEntityインスタンスの取得が行われています。
33
Query
WAS
WAS V7
V7 W/S
W/S
Entity永続化状態取得のためのインターフェース
Java Persistence Query Language （JPQL）を実行できる
以下の三種類がある
静的クエリー
動的クエリー
ネイティブ･クエリー
Entityに事前定義したクエリーの呼び出し
呼び出し側プログラムで整形したクエリーの実行
SQLの直接実行
新たに加わった機能
複数行の更新・削除 / JOIN / GROUP BY、HAVING、副照会・・・
名前付きパラメーターの使用
Query
Queryインターフェースを介し
永続化状態取得を依頼
select e from Employee e where
e.phone like ‘1804%’
EntityManager
PersistenceContext
EMPLOYEE表
employee
PHONE=1804-2222
クライアント･プログラム
Query結果Employeeの
インスタンスを取得
DBへの永続化
インスタンス作成
EMP_ID
NAME
PHONE
111111
Nakajima
1084-1111
222222
Hirabayashi
1804-2222
333333
Yamaguchi
1803-3333
WebSphere Application Server V7
Announcement Workshop 2008
# 34
© IBM Corporation.
ここでご紹介するQueryもEntityManager同様、クライアントから使用されるインターフェースで
す。DBアプリケーションのSQLに相当する、Java Persistence Query Language（JPQL：以前
のEntity BeanでのEJBQLに相当）という操作言語をQueryインターフェースに引き渡すことで
Entityを取得します。
これまでのEntity BeanではEntity側に取得されるEJBQLを書き込んでおいて使用する静的ク
エリーのみ対応していました。これはオブジェクト指向の概念からは正しいのですが、データ
ベース･アクセスの観点からは自由度が制限されるものでした。Queryはクライアント側での
JPQLの生成実行、動的クエリーに対応しています。さらに多少手間はかかりますがネイティブの
SQLを実行することも可能ですので、データ･アクセスの自由度はかなり向上しているといえます。
また参照だけでなくJDBCのexecuteUpdate()メソッドのような複数行の更新・削除（バルク・
アップデート／デリート）への対応、JOINの実行、副照会の実行、GROUP BY/HAVING文節の
使用、名前付きパラメーターの使用などが新たに出来るようになっています。
34
(参考) Query 例
WAS
WAS V7
V7 W/S
W/S
静的クエリー
静的クエリー
Entity
Employee
EntityにNamedQueryを定義
@Entity
@Entity
@Table(name="EMPLOYEE",schema=“JPATEST")
@Table(name="EMPLOYEE",schema=“JPATEST")
@NamedQuery(name="getMKEmployees",query="select
@NamedQuery(name="getMKEmployees",query="select ee from
from Employee
Employee ee where
where e.phone
e.phone like
like
'1804%'")
'1804%'")
public
public class
class Employee
Employee implements
implements Serializable
Serializable {{
…
…
クライアントよりNamedQueryを指定して実行
クライアント
動的クエリー
動的クエリー
クライアント
…
…
public
public List<Employee>
List<Employee> findMKEmplStatic()
findMKEmplStatic() {{
Query
Query query
query == em.createNamedQuery("getMKEmployees");
em.createNamedQuery("getMKEmployees");
List<Employee>
List<Employee> employees
employees == query.getResultList();
query.getResultList();
return
return employees;
employees;
}}
…
…
クライアントよりQueryを作成して実行
…
…
public
public List<Employee>
List<Employee> findMKEmpDynamic()
findMKEmpDynamic() {{
String
String queryText
queryText == "select
"select ee from
from Employee
Employee ee where
where e.phone
e.phone like
like '1804%'";
'1804%'";
Query
Query query
query == em.createQuery(queryText);
em.createQuery(queryText);
List<Employee>
List<Employee> employees
employees == query.getResultList();
query.getResultList();
return
return employees;
employees;
}}
…
…
WebSphere Application Server V7
Announcement Workshop 2008
# 35
© IBM Corporation.
静的クエリーおよび動的クエリーのサンプルを掲載します。
上にある静的クエリーの例では、まずEntity側にクエリーを定義しておきます。@Entityアノ
テーションの下に、@NamedQueryというアノテーションにて「getMKEmployee」という名前で
JPQLを定義します。JPQLの中身は「select <取得列> from <Entity> where <条件節>」といっ
た感じで、SQLを書いたことがある方でしたら容易に理解できる内容になっています。クライアン
トはQueryインターフェースをEntityManagerを介してインスタンス化し（ここでは
em.createNamedQuery()メソッドを使用）、Entityに定義した「getMKEmployee」を指定してい
ます。このQueryのインスタンスに対し、getResultList()メソッドで結果行の集合を取得していま
す。
下の動的クエリーの例では、クライアントでEntityManagerのcreateQuery()メソッドに直接
JPQLを書き込み、実行しています。実行内容は同じですが、Entityに事前定義が要らないとい
う点で自由度が高いことに着目してください。
35
Entityの操作例
WAS
WAS V7
V7 W/S
W/S
EMPLOYEEテーブルに新しいレコードをINSERTする
EMPLOYEEテーブルに対応するEntity Employeeクラスをインスタンス化
Employee emp = new Employee(444444,”Ueda”,”1804-4444”)
EntityManagerを取得し、persistメソッドを使用
EntityManagerはアノテーションで取得できる
em.persistent(emp)
(emは上で取得したEntityManagerへの参照)
persistメソッドはEntityをPersistentContextに移し、テーブルへのINSERTを行う
テーブルへのINSERTはトランザクションコミット時。明示的にflushメソッドを使用し
てINSERTさせることも可能
Employeeクラスのインスタンス化
Employee emp = new Employee(444444,”Ueda”,”1804-44442)
EntityManager em
PersistenceContext
Employeeクラス
emp_Idフィールド
nameフィールド
phoneフィールド
Employeeインスタンス
emp_Id=4444
name=Ueda
phone=1804-4444
インスタンスのpersistent命令
em.persist(emp)
Employeeインスタンス
emp_Id=4444
name=Ueda
phone=1804-4444
EMPLOYEE表
EMP_ID
NAME
PHONE
111111
Nakajima
1084-1111
222222
Hirabayashi
1804-2222
333333
Yamaguchi
1803-3333
444444
Ueda
1804-4444
トランザクションコミット時にDB
に反映
WebSphere Application Server V7
Announcement Workshop 2008
# 36
© IBM Corporation.
Entityの操作例としてEmployeeテーブルに新しいレコードを挿入する場合を取り上げてみま
す。
まず、挿入したいデータを代入する形でEntityインスタンスを作成します。作成後、
EntityManagerを取得し、Entityインスタンスに対してEntityManagerのpersistentメソッドを実行
します。メソッド実行時にインスタンスはPersistentContextに移され、DB上のテーブルとの同期
を待ちます。この状態でトランザクションがコミットされるか明示的にflushメソッドが実行されると
Entityインスタンスの持つ情報がテーブルへと反映されます。
JPAでは、このように実際のSQLを意識することなくオブジェクトの操作でテーブルへの情報更
新が可能です。
36
(参考) Entityの操作例 - INSERT
WAS
WAS V7
V7 W/S
W/S
@Stateless
@Stateless
public
public class
class EmployeeTaskImpl
EmployeeTaskImpl implements
implements EmployeeTask
EmployeeTask {{
@PersistenceContext
@PersistenceContext
EntityManager
EntityManager em;
em;
@PersistenceContextを指定して
@PersistenceContextを指定して
EntityManagerを取得
EntityManagerを取得
EntityTracsaction
EntityTracsaction et
et == em.getTransaction();
em.getTransaction();
et.begin();
et.begin();
Employee
Employee emp
emp == new
new Employee(444444,
Employee(444444, "Ueda",
"Ueda", "1804-4444");
"1804-4444");
em.persist(emp);
em.persist(emp);
et.commit();
et.commit();
Employeeエンティティインスタンスを作成してpersist
Employeeエンティティインスタンスを作成してpersist
em.close();
em.close();
Commit時にテーブルに反映される
Commit時にテーブルに反映される
WebSphere Application Server V7
Announcement Workshop 2008
# 37
© IBM Corporation.
前ページの操作のコーディング例です。
37
WAS V7でのEJB3.0
WebSphere Application Server V7
Announcement Workshop 2008
WAS
WAS V7
V7 W/S
W/S
# 38
© IBM Corporation.
38
EJB3.0のWAS V7上での使用
WAS
WAS V7
V7 W/S
W/S
Java EEアプリケーションをWASで使用するときのステップ
アプリケーションの開発
この章の範囲
アプリケーションのアセンブル・パッケージング
アプリケーションのデプロイ
チューニング
アプリケーション運用
WebSphere Application Server V7
Announcement Workshop 2008
# 39
© IBM Corporation.
WAS V7でEJB3.0を使用するときのステップを考えます。
まず、アプリケーションコンポーネントの開発があり、その後、必要なファイルなどをパッケージ
ングし、WAS V7環境へのデプロイという形でアプリケーションをインストールします。インストー
ル後、パフォーマンステストなどを行いながらチューニングを実施し、リリースした後はアプリケー
ションの運用を行っていくことになります。アプリケーション開発については後続のセッションで説
明予定で、アプリケーション運用については昨日のセッションで説明を行いましたので、ここでは
パッケージング、デプロイ、チューニングの３つのポイントについて考えていきます。
39
パッケージング
WAS
WAS V7
V7 W/S
W/S
エンタープライズアプリケーションのパッケージング
EARファイル
EJB-JARファイル
*.class
*.jar (ライブラリ)
ejb-jar.xml
ibm-ejb-jar-bnd.xml
MANIFEST.MF
application.xml
MANIFEST.MF
WARファイル
web.xml
ibm-web-bnd.xml
ibm-web-ext.xml
*.class
*.jar (ライブラリ)
WebSphere Application Server V7
Announcement Workshop 2008
# 40
© IBM Corporation.
エンタープライズアプリケーションのパッケージングです。各モジュールごとに配置するデプロ
イメント記述子 (一部はIBM拡張)を右側に記載しています。このディレクトリやファイル配置場所
といったパッケージングはJava EE 5でもJ2EE1.4と変わりはありません。
40
デプロイメント記述子の省略
WAS
WAS V7
V7 W/S
W/S
Java EE 5ではデプロイメント記述子の省略が可能
application.xmlの省略
省略した場合は以下のようにみなされる
拡張子が.warならWebモジュールとみなされ、コンテキストルートはファ
イル名から.warを除いたものになる
拡張子が.jarでejb-jar.xmlが存在するか、@statelessか@statefulアノ
テーションを含むクラスがあればEJBモジュール
ejb-jar.xmlの省略
アノテーションの利用により参照情報が十分取得できれば省略可
EJBコンテナがアノテーションのスキャンをおこなう
web.xmlについては事実上省略不可
Servlet、Filter、Listenerが
含まれる場合は省略不可
デプロイ時に自動で
ファイルを生成
WebSphere Application Server V7
Announcement Workshop 2008
# 41
© IBM Corporation.
Java EE 5ではデプロイメント記述子の省略が可能になっています。
EARのデプロイメント記述子であるapplication.xmlが省略された場合、存在するモジュール名
の拡張子によってどういうタイプのモジュールかが判断されます。拡張子が.warの場合はWebモ
ジュール、.jarでかつejb-jar.xmlが存在すればEJBモジュールという具合にです。また、ejbjar.xmlもアノテーションを用いて充分な設定がされていれば省略することが可能です。
ただし、web.xmlはServlet、Filter、Listernerのどれかが含まれる場合には省略ができません
ので、多くの場合、省略することは難しいでしょう。また、パッケージングの際には省略が可能で
すが、WASにデプロイをすると省略されたデプロイメント記述子はWASによって作成されます。
いずれのデプロイメント記述子も管理コンソールから確認する事が出来ます。
application.xml：
エンタープライズ・アプリケーション＞アプリケーション名＞デプロイメント記述子の表示
web.xml/ejb-jar.xml：
エンタープライズ・アプリケーション＞アプリケーション名＞モジュールの管理＞モジュール名＞
デプロイメント記述子の表示
WAS V7 InfoCenter - EJB 3.0 module packaging overview
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.webspher
e.nd.doc/info/ae/ae/cejb_packfep.html
41
デプロイ(1/2)
WAS
WAS V7
V7 W/S
W/S
EJBのデプロイメント
EJBモジュールをWASで動かすにはデプロイメントコードと呼ばれる追加のクラ
スを生成する必要がある
EJB2.1以前ではEJBDeployコマンドを使用
EJB3.0モジュールでは不要
JITデプロイメント
EJB3.0ではJITデプロイメントと呼ばれる機能が追加されている
アプリケーション起動時にメモリー上にデプロイメントコードを自動的に生成
必要なし
WebSphere Application Server V7
Announcement Workshop 2008
# 42
© IBM Corporation.
次はデプロイについてです。
開発したEJBコンポーネントをWAS上で稼動させるにはデプロイメントコードと呼ば
れる追加のクラスを生成する必要があります。EJB2.1以前ではEJBDeployコマンドを
用いてデプロイメントコードを生成していました。
それに対し、EJB3.0ではJITデプロイメントという機能が追加されました。これはアプ
リケーション起動時にメモリー上にデプロイメントコードを自動的に生成してくれる機能
です。これによりEJB3.0ではEJBDeployコマンドを実行する必要はなくなりました。な
お、EJB3.0モジュールに対してEJBDeployコマンドを実行させることもできますが、何
もおこりません。
42
デプロイ(2/2)
WAS
WAS V7
V7 W/S
W/S
JITデプロイメントが使用できない場合の代替ツール
createEJBStubsコマンド
EJBクライアントがEJB3.0をサポートしない環境の場合はツールで
スタブクラスを生成する必要がある
例：
J2SEクライアント、FP-EJB3.0が適用されていないWAS V6.1以前の
コンテナ、WAS環境以外の場合等
<WAS_root>/bin/createEJBStubs.bat(.sh)
ejbdeployコマンド
EJB2.1以前のバージョンのデプロイで使用
デプロイ時、または開発時に管理コンソール、コマンドライン、開
発ツール上のいずれかで実行
EJB3モジュールでは何も起こらない
EJB2.1のモジュールが含まれるアプリはejbdeployコマンドをオプ
ション付きで実行する
<WAS_root>/bin/ejbdeploy.bat(.sh) -complianceLevel 5.0
WebSphere Application Server V7
Announcement Workshop 2008
# 43
© IBM Corporation.
JITデプロイメントはWAS V7およびWAS V6.1でEJB3.0 Feature Packが適用されている環
境でのみ使用することができます。これ以外の場合は利用できませんので、別のツールを使用
する必要があります。
たとえば、EJBクライアントがWAS V7またはWAS V6.1 EJB3.0 Feature Packの環境下にな
い場合は、createEJBStubコマンドを使用してスタブクラスを生成する必要があります。また、
EJB3.0とEJB2.1のモジュールが混在するなどの場合には、WASV6.1以前の環境と同様に
EJBDeployコマンドの実行が必要です。
WAS V7 InfoCenter - Create stubs command
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.webspher
e.nd.doc/info/ae/ae/rejb_3stubscmd.html
WAS V7 InfoCenter - The ejbdeploy command
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.etools.ejb
batchdeploy.doc/topics/regenc.html
43
バインディング(1/2)
WAS
WAS V7
V7 W/S
W/S
EJB3.0のビジネスインターフェースはWASのネーミングサービスに紐付け
られる
これをバインディングという
バインディングファイル(ibm-ejb-jar-bnd.xml)を用いてバインディングを定
義できる
<ejb-jar-bnd xmlns“ ・・・ version="1.0">
<session name="CalcBean">
<interface class="test.ejb.Calc" binding-name="ejb/Calc"/>
</session>
</ejb-jar-bnd>
インターフェースがローカルかリモートかによって2種類の名前空間が用
意される
ローカルインターフェースの場合は同一JVM内のみで有効な名前空間
「ejblocal:」で始まる
リモートインターフェースの場合は他のJVMからもアクセス可能なグローバル
な名前空間
WebSphere Application Server V7
Announcement Workshop 2008
# 44
© IBM Corporation.
アプリケーションデプロイ時にEJB3.0のビジネスインターフェースはWASのネーミングサービ
スに紐付けられます。これをバインディングと呼びます。バインディングファイルが存在しない場
合には、ここに記載したルールに従ってデフォルトのバインディングが割り当てられます。
インターフェースがローカルかリモートかによって2種類の名前空間が用意されます。
WAS V7 InfoCenter「Application bindings」
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.webspher
e.nd.doc/info/ae/ae/crun_app_bindings.html
WAS V7 InfoCenter「EJB 3.0 application bindings overview」
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.webspher
e.nd.doc/info/ae/ae/cejb_bindingsejbfp.html
44
バインディング(2/2)
WAS
WAS V7
V7 W/S
W/S
EJB3.0ではバインディングファイルを省略することも可能
EJB2.1までバインディングファイル(ibm-ejb-jar-bnd.xmi)が常に必要
ルールにしたがってデフォルトのバインディングをコンテナが定義して
くれる
long、shortの2種類のバインディングを定義
shortの方がシンプルでポータビリティは高いが、異なるクラスが同名のイン
ターフェースを持つ場合は使用できない
EAR名： CalcEJB3EAR
モジュール名： CalcEJB3EJB
コンポーネント名： test.ejbCalcBean
リモートインターフェース： test.ejb.Calc
long
dumpNamespaceコマンド出力
28 (最上位)/nodes/AA315630Node02/servers/server1/ejb/CalcEJB3EAR/CalcEJB3EJB.jar/CalcBean#test.ejb.Calc
28
test.ejb.Calc
…
44 (最上位)/nodes/AA315630Node02/servers/server1/test.ejb.Calc
44
test.ejb.Calc
short
WebSphere Application Server V7
Announcement Workshop 2008
# 45
© IBM Corporation.
バインディングファイルが存在しない場合には、ここに記載したルールに従ってデフォルトのバ
インディングが割り当てられます。
デフォルトのバインディングはshort、longの2種類が定義されます。
shortはパッケージを含めたインターフェース名でlongはアプリケーション名、モジュール名、コ
ンポーネント名をもとに決定されます。
shortの方がシンプルでポータビリティは高いですが、異なるクラスが同名のインターフェース
を持つ場合は使用できません。
その場合は、shortをdisableにする必要があります。
WAS V7 InfoCenter「Application bindings」
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.webspher
e.nd.doc/info/ae/ae/crun_app_bindings.html
WAS V7 InfoCenter「EJB 3.0 application bindings overview」
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.webspher
e.nd.doc/info/ae/ae/cejb_bindingsejbfp.html
45
チューニングポイント
WAS
WAS V7
V7 W/S
W/S
スレッドプール
Webコンテナースレッドプール
ORBスレッドプール
EJBコンテナ
Webコンテナー
スレッド・プール
ORB
スレッド・プール
Application
Application
Server
Server
(WebContainer)
(WebContainer)
Object
Application
Object
Application
Request
Server
Request
Server
Broker
(EJBContainer)
Broker (EJBContainer)
DB
Local or Remote
WebSphere Application Server V7
Announcement Workshop 2008
# 46
© IBM Corporation.
EJBを使用する場合のチューニングポイントについてお話します。
リクエストキューイングの考え方から、まずポイントとして挙げられるのはスレッドプールです。
EJBを使用している場合にはWebコンテナースレッドプールおよびORBスレッドプールで並列
度の制御を行います。
またEJBコンテナにもチューニング可能な項目がありますので、いくつかのパラメータについて
説明します。
46
スレッド･プールのチューニング
WAS
WAS V7
V7 W/S
W/S
Webコンテナスレッド・プール
ローカルインターフェース使用時はEJBコールもWebコンテナーのス
レッドで処理される
Webコンテナー・スレッドプールをチューニング
ORBスレッド・プール
リモートインターフェースを使用している場合はEJBコールの際には
ORBスレッドを使用される
ORBスレッド・プールをチューニング
Concurrency
Webコンテナー
スレッド・プール
Application
Application
Server
Server
(WebContainer)
(WebContainer)
Concurrency
ORB
スレッド・プール
Object
Application
Object
Application
Request
Server
Request
Server
Broker
Broker (EJBContainer)
(EJBContainer)
WebSphere Application Server V7
Announcement Workshop 2008
# 47
© IBM Corporation.
まずはスレッド・プールのチューニングについてです。
EJBクライアントとEJBコンテナーが同一アプリケーションサーバー上に配置されている場合に
は、ローカルインターフェースを使用することが可能です。この場合にはEJBコンテナーが受ける
リクエスト数について設定することはできません。 並列度はクライアント側、つまりWebコンテナ
のスレッド・プールサイズを調整します。
EJBクライアントからリモートインターフェースでEJBにアクセスする際にはORBスレッドプール
の調整が必要です。
47
(参考)Webコンテナスレッド・プールのチューニング
WAS
WAS V7
V7 W/S
W/S
Webコンテナのプールサイズ設定
Webコンテナーの並列度を設定
WebSphere Application Server V7
Announcement Workshop 2008
# 48
© IBM Corporation.
管理コンソールより、以下を選択して下さい。
サーバー>Webコンテナー・トランスポート・チェーン>WCInboundDefault>TCP インバウンド・
チャネル (TCP_2) >スレッド・プール > WebContainer
48
(参考)ORBスレッド･プールのチューニング
WAS
WAS V7
V7 W/S
W/S
アプリケーションサーバーを選択し、[コンテナーサービス]→[ORBサービス]
リモートのEJBクライアントからアクセスがある場合にはスレッド・プールを設定
設定画面へはORBサービス画面、または追加プロパティの[スレッド・プール]から
スレッドプールのデフォルトは最大50スレッド、最小10スレッド
非活動タイムアウトを使用してアイドル状態にあるスレッドを開放
ORBスレッドプールの
スレッド数を設定
空きスレッドは小まめに開放
ORB接続オブジェクトの
キャッシュサイズを指定
WebSphere Application Server V7
Announcement Workshop 2008
# 49
© IBM Corporation.
リモートのEJBクライアントからのアクセスに対しては最大・最小スレッド数を設定することが可
能です。設定は管理コンソールからアプリケーションサーバー選択し、[コンテナーサービ
ス]→[ORBサービス]→[スレッド・プール]の画面から最大・最小サイズを設定します。デフォルト
は最大サイズが50スレッド、最小サイズが10スレッドです。
49
EJBコンテナのチューニング
WAS
WAS V7
V7 W/S
W/S
EJBコンテナでチューニングできるパラメータ
インスタンスプールサイズ
Stateless Session Bean / Message Driven Beanのインスタンスは一定個数
プールされる
TPVなどで最適なプールサイズを算出する
EJBキャッシュ・サイズ
Stateful Session Beanはデフォルト設定では、このサイズを越えると永続化
されてしまう
インスタンス
プール
Object
Application
Object
Application
Request
Server
Request
Server
Broker
Broker (EJBContainer)
(EJBContainer)
EJBキャッシュ
WebSphere Application Server V7
Announcement Workshop 2008
# 50
© IBM Corporation.
EJBコンテナでチューニングできるパラメータの一部をここでは扱います。
Stateless Session Bean、Message Driven Beanのインスタンスは作成、削除のオーバー
ヘッドを抑えるために一定個数、プールされます。このプールサイズはTPVなどで確認しながら
新たなインスタンス作成や破棄などの負担が少なくなるように、最適な値を算出すると良いでしょ
う。
Stateful Session BeanやEntity BeanはEJBコンテナによってキャッシュされます。特に
Stateful Session Beanはこのキャッシュサイズを越えると永続化されてしまい、その処理によっ
てパフォーマンスがダウンする可能性があります。こちらはEJBトレースなどを用いて最適値を探
ることができます。
50
(参考)EJBコンテナのインスタンス・プールサイズのチューニング
WAS
WAS V7
V7 W/S
W/S
EJBインスタンス・プールサイズの設定
Java仮想マシンの汎用JVM引数に設定
-Dcom.ibm.websphere.ejbcontainer.poolSize=<application_name>
#<module_name>#<enterprisebean_name>=<minSize>,<maxSize>
（設定例） ivtApp#ivtEJB.jar#ivtEJBObject=125,1327
TPVにて確認
プール内のインスタンスの大多数を使用している場合、プールサイズを大きくする
はじめは、最小と最大サイズを等しく設定する
WebSphere Application Server V7
Announcement Workshop 2008
# 51
© IBM Corporation.
このプロパティーはStateless Session Bean、Message Driven Bean、Entity Bean に対して
適用されます。管理コンソールより、以下を選択して設定してください。値を指定しない場合は、
コンテナーのデフォルト値であるminSize50、maxSize500 が使用されます。
サーバー>プロセス定義>Java仮想マシン>汎用JVM引数
WAS V7 InfoCenter - EJB container system properties
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.webspher
e.nd.doc/info/ae/ae/rejb_ecnt.html
51
(参考)EJBキャッシュの設定
EJBキャッシュの設定
WAS
WAS V7
V7 W/S
W/S
クリーンアップ間隔
コンテナーがキャッシュから未使用アイテムを除
去する間隔（ミリ秒）
デフォルトは3000
キャッシュサイズ
EJBコンテナ内のアクティブ・インスタンスの数
通常時に予想されるアクティブ・インスタンスの
最大数を設定する
デフォルトは2053
WebSphere Application Server V7
Announcement Workshop 2008
# 52
© IBM Corporation.
管理コンソールより、以下を選択して下さい。
サーバー>EJBキャッシュ設定
WAS V7 InfoCenter - EJB cache settings
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.webspher
e.nd.doc/info/ae/ae/uejb_rcash.html
52
(参考)EJBキャッシュのチューニング
WAS
WAS V7
V7 W/S
W/S
トレースによるEJBキャッシュのチューニング
設定
com.ibm.ejs.util.cache.BackgroundLruEvictionStrategy=all=enabled:com.ibm.ejs.util.c
ache.CacheElementEnumerator=all=enabled
出力例
[省略] BackgroundLru 3
[省略] BackgroundLru 3
[省略] BackgroundLru 3
…
[省略] BackgroundLru <
EJB Cache: Sweep (82,40) - Cache limit not reached : 0/2053
EJB Cache: Sweep (83,40) - Cache limit not reached : 0/2053
EJB Cache: Sweep (84,40) - Cache limit exceeded : 3589/2053
EJB Cache: Sweep (84,40) - Evicted = 50 : 3589/2053 Exit
チューニング方法
「Cache limit」,「Evicted」を検索する
Cache limit not reached
設定値が適切かそれ以上である。
Cache limit exceeded
使用中のBean数が、指定された容量を超えて
いる。
Evicted
キャッシュ制限を超えた場合、出力される事がある。
システム全体のメモリー使用量を考慮し、 EJBキャッシュサイズをチューニングする
WebSphere Application Server V7
Announcement Workshop 2008
# 53
© IBM Corporation.
EJBキャッシュをチューニングするには、トレースを設定し出力されたメッセージを元にします。
トレースの設定方法と、トレースの出力例を記載しました。
EJB キャッシュ設定値はハード制限ではなく、容量がこの設定値を超えることがあります。この
制限に達しても、EJB コンテナーはキャッシュへの Bean の追加を停止しません。これは、キャッ
シュがフルになったとき、Bean に対する要求が実現されなかったり、少なくともキャッシュ・サイ
ズが制限以下になるまで遅延するということを意味します。つまり、キャッシュ制限を超えることが
あっても、EJB コンテナーはキャッシュをクリーンアップして EJB キャッシュ・サイズ未満に保持
することを試みます。
分析の結果、EJB コンテナの観点から EJB キャッシュを最適に設定することは可能ですが、
その値はWASの観点からすると最適ではない可能性があります。キャッシュ・サイズが大きい方
がヒット数は高くなり、EJB キャッシュのパフォーマンスは向上しますが、メモリー使用量は増加し
ます。キャッシュに使用されるメモリーはその製品の他の領域では使用できないので、全体的な
パフォーマンスが低下する可能性があります。メモリーが豊富にあるシステムでは、パフォーマン
スの低下は問題にならず、EJB キャッシュを適切にチューニングすることで全体的なパフォーマ
ンスが向上します。ただし、キャッシュを構成するときには、システムのパフォーマンスと EJB
キャッシュのパフォーマンスを対比させて考慮する必要があります。
WAS V7 InfoCenter「Tuning the EJB cache using the trace service」
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.webspher
e.nd.doc/info/ae/ae/tejb_tunecash.html
53
(参考)トレースの取得
WAS
WAS V7
V7 W/S
W/S
EJBに関して取得できるトレースのストリングが追加
com.ibm.ws.ejbcontainer,*=all
デプロイ時のJITデプロイメントの経緯が取得可能
[省略] EJBLinkObject 3 bean name specified (HelloBean), looking for home in same/specified
module...
[省略] EJBLinkObject 3 looking for home in other modules...
[省略] JITDeploy
> validateInterfaceBasics : TestDBEAR#TestDBEJB.jar#HelloBean Entry
[省略] EJBUtils
3 validateEjbClass : successful : test.session.HelloBean
[省略] JITDeploy
< validateInterfaceBasics : TestDBEAR#TestDBEJB.jar#HelloBean Exit
com.ibm.ws.injectionengine.*=all
デプロイ時のインジェクションの内容と参照解決の経緯が取得可能
[省略] EJBProcessor < resolve Exit
JndiName=
servlet.CalcServlet/calc
Annotation=
@javax.ejb.EJB(name=, beanInterface=class java.lang.Object,
beanName=, mappedName=, description=)
Injected Type/Object= interface test.ejb.Calc/null
Binding Object =
Reference Class Name: test.ejb.Calc
[省略]
アノテーションの指定の内容と
取得オブジェクトの情報
WebSphere Application Server V7
Announcement Workshop 2008
# 54
© IBM Corporation.
WAS V7ではV6.1と比較して、EJBコンテナの動きに関して取得できるトレースの内容が追加
されます。特にJITデプロイメントやアノテーションによるインジェクションなどWAS V7が自動的
に内部で行っている動作については、開発者や管理者の負担は軽減された反面、問題が起き
た時の問題判別が行いにくいという点がネックです。これらのトレースストリングはそれらの問題
が起きたときに有用です。
54
Java SE 6
WebSphere Application Server V7
Announcement Workshop 2008
WAS
WAS V7
V7 W/S
W/S
# 55
© IBM Corporation.
ここからはJava SE 6とありますが、主にランタイムの話を中心に進めていきます。
55
IBM SDK for Java Version 6
WAS
WAS V7
V7 W/S
W/S
WebSphere Application Server V7.0ではJDKとしてIBMが開発したIBM SDK
for Java Version 6 を使用
Java SE 6の仕様に準拠
Java SE 6はEoD、XML & Web Servicesサポートなどを目標に仕様策定され
ている
JSR 270: JavaTM SE 6 Release Contents
IBM SDK for Java Version 6は前バージョンと比較してパフォーマンス面で
いくつかの改良がなされている
共有クラスキャッシュ
参照の圧縮
56
WebSphere Application Server V7
Announcement Workshop 2008
# 56
© IBM Corporation.
WAS V7ではJDKとしてIBM SDK for Java Version 6 を使用しています。このJDKはJava
SE 6の仕様に準拠しています。またVersion 5のときと比較してパフォーマンス関連での改良が
なされています。
56
JDBC4.0
WAS
WAS V7
V7 W/S
W/S
JDBCドライバーによる接続の妥当性検査
タイムアウト期間内において、DB接続をアプリケーションに割り当てる
前に検証する
接続検証が有効に設定されている場合のみ設定可
JDBC仕様レベル4.0以上に準拠したJDBCドライバー
接続検証
新規接続の検証、既存プールの検証
SQL照会による検証は、V7では非推奨
エラー検出モデル
例外マッピングモデルの使用(デフォルト)
JDBCドライバーによってスローされた例外を、データ・ストア・ヘルパーのエラーマップに定義された例外で置換する
例外検査モデルの使用
JDBCドライバーによってスローされた例外を、データ・ストア・ヘルパーのエラーマップに定義された例外で置換しない
WebSphere Application Server V7
Announcement Workshop 2008
# 57
© IBM Corporation.
Java SE 6での仕様追加のひとつとしてJDBC4.0があります。WAS V7ではJDBC4.0の機能に
対応したデータソースの接続検証プロパティーという設定が追加されています。
また、JDBC関連でエラー検出モデルという設定項目が追加されています。
接続検証プロパティおよびエラー検出モデルは、管理コンソールより、「リソース > JDBC >
データ・ソース > WebSphere Application Server データ・ソース・プロパティ」を選択すると表示
されます。
57
(参考)Java Standard Edition Platform, Version 6
WAS
WAS V7
V7 W/S
W/S
IBM SDK for Java Version 6 は Sun® Java 仕様に準拠
JSR 173: Streaming API for XML
JSR 222: Java Architecture for XML Binding (JAXB) 2.0
JSR 224: Java API for XML-based Web Services (JAX-WS) 2.0
JSR 118: Web Services Metadata for the Java Platform
JSR 250: Common Annotations for the Java Platform
JSR 269: Pluggable Annotation Processing API
JSR 221: JDBC 4.0 API Specification
JSR 199: Java Compiler API
JSR 223: Scripting for the Java Platform
JSR 202: Class file specification update
WebSphere Application Server V7
Announcement Workshop 2008
# 58
© IBM Corporation.
Java SE 6の仕様です。
58
ランタイム環境 – プラットフォームごとの違い
WAS
WAS V7
V7 W/S
W/S
Windows, AIX, Linux, z/OS
The IBM SDK for Java Version 6を使用
System i プラットフォームでは Java ランタイムはOS の一部
アプリケーション・サーバーにはバンドルされない
J9 と Classic の 2つのバージョンを利用可能
Solaris と HP はハイブリッド JDK を使用
ランタイムは IBM のものではない
IBM XML、セキュリティ、ORB ライブラリをバンドル
WebSphere Application Server V7
Announcement Workshop 2008
# 59
© IBM Corporation.
WAS V7の前提となるJDKはプラットフォームによって異なります。 IBM SDK for Java
Version 6はWindows、AIX、Linux、z/OSのプラットフォームで前提となるJDKで
す。SolarisとHPのJDKのランタイムはIBMのものではなく、Sun Hotspotを基本にして
IBMのライブラリを付加したものになります。
System iについては後続のセッションで詳しく説明します。
59
共有クラスキャッシュ
WAS
WAS V7
V7 W/S
W/S
共有クラスキャッシュとは
複数のJVM間で共通して使用するクラスを共有できるようにする仕組み
JVMの起動時間の縮小と使用メモリのフットプリント減少に効果がある
IBM SDK for Java 5 で導入
デフォルトでは有効
JVM引数に-Xshareclasses:noneを指定することで無効にできる
JVMの使用するメモリ
JITコードキャッシュ
JVM 1
Heap領域
Class Memory Segments
ディスク上の
クラス
重複するクラス
を共有
Class Memory Segments
JVM 2
Heap領域
JITコードキャッシュ
WebSphere Application Server V7
Announcement Workshop 2008
# 60
© IBM Corporation.
JVMのパフォーマンス向上の仕組みのひとつとして共有クラスキャッシュがあります。これは
IBM JDK V5で導入されたもので、複数のJVM間で使用するクラスを共有する仕組みです。この
機能を用いることによりJVMの起動時間の短縮と使用メモリのフットプリントを減少させることがで
きます。
デフォルトで有効になっており、無効化するにはにはJVM汎用引数に-Xshareclasses:none
を指定します。
WAS V7 InfoCenter – Java virtual machine settings
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.webspher
e.nd.doc/info/ae/ae/urun_rconfproc_jvm.html
60
共有クラスキャッシュ – V6での改良点
WAS
WAS V7
V7 W/S
W/S
V6ではOS再起動をまたいで共有クラスキャッシュの情報を保
持することが可能
V5ではOS再起動の際にキャッシュ情報は消去されていた
V6ではキャッシュ情報をファイルに書き出すことによりOS再起動をまた
いで情報を保持することを可能にしている
JVM汎用引数で設定
有効
無効
-Xshareclasses:persistent
-Xshareclasses:nonpersistent
WebSphere Application Server V7
Announcement Workshop 2008
# 61
© IBM Corporation.
共有クラスキャッシュはIBM JDK V5で導入されましたが、V6でいくつかの改良がされています。
V5ではOSを再起動させるとキャッシュ情報はクリアされてしまいましたが、V6ではファイルに書
き出すことによってOS再起動をまたいでキャッシュ情報を保持させることが可能になっています。
これによりOS再起動後の最初のJVM起動時間の短縮がはかれます。
またV6ではキャッシュできるデータタイプも増えています。
Java Diagnostics Guide 6 - Class data sharing command-line options
http://publib.boulder.ibm.com/infocenter/javasdk/v6r0/index.jsp?topic=/com.ibm.java.doc.
user.aix32.60/user/sharedclassesxoptions.html
61
参照の圧縮 (Compressed references)
WAS
WAS V7
V7 W/S
W/S
WAS V6.1では64bit版が32bit版と比較してヒープ使用量が60%程度増加
64bit版ではオブジェクト参照のポインターが8バイト（32bit版の倍）
WAS V7.0 64bit版ではポインターを圧縮することによって必要なヒープ使
用量を削減する機能を実装
ランタイムは内部で 32bit 参照と 64bit ポインタを変換
64bit IBM JDK において、ヒープサイズが約29GB以下（プラットフォー
ムごとに異なる）の場合に利用可能
Solaris 64bit JVM、HP-UX 64bit JVM、iSeries Classic 64bit JVMではサ
ポートされない
デフォルトは使用不可
有効化するには –Xcompressedrefs オプションを使用
WebSphere Application Server V7
Announcement Workshop 2008
# 62
© IBM Corporation.
V6.1では64bit版が32bit版と比較してヒープ使用量が多く、比較すると60％程度増加する傾
向にありました。これはオブジェクト参照のポインターサイズは32bit版が4バイトであるのに対して
64bit版では8バイトであるのが大きな原因でした。
V7でもV6.1と同じく64bit版のヒープ使用量の方が32bit版よりも同程度大きくなりますが、これ
に対する機能として参照の圧縮(Compressed references)が導入されています。これは文字通
り64bit版の8バイトの参照を4バイトに圧縮する機能でヒープ使用量の削減に効果があります。
ただし、ヒープサイズが29GB以下(サイズはプラットフォーム依存)の場合に限られ、Soraris
64bit JVMなどサポートされないプラットフォームもあります。
この機能はデフォルトでは使用不可となっており、JVM汎用引数に-Xcompressedrefsを指定
することによって有効化できます。
WAS V7 InfoCenter - Tuning the IBM virtual machine for Java
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.webspher
e.nd.doc/info/ae/ae/tprf_tunejvm_v61.html
62
32bit版 vs 64bit版
WAS
WAS V7
V7 W/S
W/S
大きなヒープを確保する必要があるときは64bit版を使用
32bit版では使用できるヒープ容量に限界がある。
AIXの場合は3.2GB。これ以上のヒープを使用する場合は64bit版を
選択する必要がある。
ヒープ消費量の観点では32bitの方が有利
同一アプリケーションのヒープ使用量を見た場合、64bit版は32bit版
と比較して使用量が増える傾向にある
約60%程度増加する傾向にある
参照の圧縮(Compressed references)の使用
この機能を用いることによって64bit版のヒープ消費量を軽減する
ことが可能
ただしCPU使用率は若干増加
WebSphere Application Server V7
Announcement Workshop 2008
# 63
© IBM Corporation.
32bit版と64bit版の選択ポイントです。
まず一つ目のポイントは最大ヒープサイズです。32bit版では使用できる最大ヒープサイズが
64bit版と比較するとかなり小さくなります（32bit版 AIXの場合は3.2GB）。32bit版の最大値を越
えるヒープを使用したいときには64bit版の選択を考える必要があります。
次のポイントはヒープ使用量です。ヒープ使用量の観点では32bit版の方が有利です。物理メ
モリが少なく、なるべくヒープ使用量を抑えたい場合などは32bit版の使用を考えてください。また
V7になって64bit版に参照の圧縮機能が追加されています。こちらも使用ヒープ量を抑えること
が可能ですが、有効にすると若干CPU使用率が増えることになりますので、ご注意ください。
63
ガーベージ・コレクター
WAS
WAS V7
V7 W/S
W/S
中核の技術は Java 5 と同様
-Xgcpolicyオプション（GCポリシー）もJava 5と同様
JVMオプション
GCの実施方法
GCの形態
-Xgcpolicy:optthruput
Stop-the-world
Mark&sweep
オプション１
-Xgcpolicy:optavgpause
concurrent
Mark&sweep
オプション２
Xgcpolicy:subpool
Stop-the-world
Mark&sweep
-Xgcpolicy:gencon
Stoｐ-the-world
(Nursery)
Concurrent
(Tenured)
Copying + Mark&Sweep
（世代別管理）
デフォルト
オプション３
変更点
パフォーマンス
クラスローダーのロード/アンロード速度とフットプリントの改善
世代別 GC ポリシー
Nursery (New) 領域サイズのデフォルト64MB制限の廃止
WebSphere Application Server V7
Announcement Workshop 2008
# 64
© IBM Corporation.
GCについてはV6.1から大きな変更はありません。GCポリシーも同じものが設定できます。各
ポリシーの詳細については以下のワークショップ資料を参照ください。
WAS V6.1アップデート・ワークショップ – J2SE 5.0
http://www.ibm.com/developerworks/jp/websphere/library/was/was61_ws/
変更点はパフォーマンス改良や世代別GCのNursery領域関連のデフォルト値などです。
Nursery領域サイズのデフォルト最大・最大値はヒープの25％か64MBのどちらか小さいほうとい
う制限がありましたが、V6ではこの64MB制限が廃止され、デフォルト値はヒープの25％となって
います。どちらにせよ、あくまでデフォルト値なので適切な値で上書きすることは可能です。
64
(参考) verbose:gc出力例
WAS
WAS V7
V7 W/S
W/S
native_stderr.log
<af type="tenured" id="22" timestamp="Oct 14 18:50:38 2008" intervalms="3270.260">
<minimum requested_bytes="32" />
<time exclusiveaccessms="0.066" meanexclusiveaccessms="0.066" threads="0" lastthreadtid="0x16A4FB00" />
<refs soft="2211" weak="12583" phantom="56" dynamicSoftReferenceThreshold="12"
maxSoftReferenceThreshold="32" />
<tenured freebytes="490496" totalbytes="61341696" percent="0" >
<soa freebytes="0" totalbytes="60851200" percent="0" />
<loa freebytes="490496" totalbytes="490496" percent="100" />
</tenured>
<gc type="global" id="26" totalid="26" intervalms="3278.903">
<finalization objectsqueued="161" />
<timesms mark="168.294" sweep="2.426" compact="0.000" total="172.628" />
<tenured freebytes="22500168" totalbytes="61341696" percent="36" >
<soa freebytes="22071112" totalbytes="60912640" percent="36" />
<loa freebytes="429056" totalbytes="429056" percent="100" />
</tenured>
</gc>
<tenured freebytes="22500136" totalbytes="61341696" percent="36" >
<soa freebytes="22071080" totalbytes="60912640" percent="36" />
<loa freebytes="429056" totalbytes="429056" percent="100" />
</tenured>
<refs soft="2122" weak="11674" phantom="56" dynamicSoftReferenceThreshold="11"
maxSoftReferenceThreshold="32" />
<time totalms="175.661" />
</af>
WebSphere Application Server V7
Announcement Workshop 2008
# 65
© IBM Corporation.
verbose:gcの出力例です。出力はV6.1と同じくnative_stderr.logにされます。
65
ダンプファイル
WAS
WAS V7
V7 W/S
W/S
Javacore
Javaプロセスが異常終了したとき、または明示的に命令を送った時に出力さ
れるテキストベースの診断情報
Javadump、Threaddumpなどとも呼ばれている。
以下のように明示的に出力させることが可能（wsadmin / Jythonの例）
wsadmin> jvm = AdminControl.completeObjectName('type=JVM,process=server1,*')
wsadmin> AdminControl.invoke(jvm, 'dumpThreads')
Heapdump
JVMがHeapを使い切ったときに生成
デフォルトの出力形式はバイナリ(拡張子.phd)
Heap上の全てのオブジェクトの情報を出力
以下のように明示的に出力させることが可能（wsadmin / Jythonの例）
wsadmin> jvm = AdminControl.completeObjectName('type=JVM,process=server1,*')
wsadmin> AdminControl.invoke(jvm, 'generateHeapDump')
WebSphere Application Server V7
Announcement Workshop 2008
# 66
© IBM Corporation.
V7でもV6.1と同様にしてJavacore、Heapdumpを生成することができます。
WAS V7 InfoCenter - Dumping threads in server processes using scripting
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.webspher
e.nd.doc/info/ae/ae/txml_dump.html
WAS V7 InfoCenter - InfoCenter - Generating heap dumps manually
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.webspher
e.nd.doc/info/ae/ae/tprf_generatingheapdumps.html
66
(参考)Javacore出力例
WAS
WAS V7
V7 W/S
W/S
Javacore内のTHREADS subcomponentセクションの出力例
javacoreYYYYMMDD.HHMMDD.<process id>.txt
NULL
-----------------------------------------------------------------------0SECTION
THREADS subcomponent dump routine
NULL
=================================
NULL
1XMCURTHDINFO Current Thread Details
NULL
---------------------3XMTHREADINFO
"SIGABRT Thread" TID:0x33994E00, j9thread_t:0x30118BFC, state:R, prio=10
3XMTHREADINFO1
(native thread ID:0x25300F, native priority:0xB, native policy:UNKNOWN)
NULL
1XMTHDINFO All Thread Details
NULL
-----------------NULL
2XMFULLTHDDUMP Full thread dump J9 VM (J2RE 6.0 IBM J9 2.4 AIX ppc-32 build jvmap326020080826_2233220080826_022332_bHdSMr, native threads):
3XMTHREADINFO
"P=568918:O=0:CT" TID:0x305EF900, j9thread_t:0x30118954, state:CW, prio=5
3XMTHREADINFO1
(native thread ID:0x23603B, native priority:0x5, native policy:UNKNOWN)
4XESTACKTRACE
at java/lang/Thread.sleep(Native Method)
4XESTACKTRACE
at java/lang/Thread.sleep(Thread.java:850)
4XESTACKTRACE
at com/ibm/ws/runtime/WsServerImpl.main(WsServerImpl.java:679)
4XESTACKTRACE
at com/ibm/ws/runtime/WsServer.main(WsServer.java:59)
4XESTACKTRACE
at sun/reflect/NativeMethodAccessorImpl.invoke0(Native Method)
4XESTACKTRACE
at sun/reflect/NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
4XESTACKTRACE
at
sun/reflect/DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37(Compiled Code))
WebSphere Application Server V7
Announcement Workshop 2008
# 67
© IBM Corporation.
JavacoreのTHREADS subcomponentセクションの出力例です。
67
(参考)Heapdump出力
WAS
WAS V7
V7 W/S
W/S
heapdumpYYYYMMDD.HHMMDD.<process id>.txt
0x00440780 [56] OBJ [Ljava/lang/String;
0x00441178 0x00441140 0x00441108 0x004410D0 0x00441098 0x00441060 0x00441028 0x00440FF0
0x00440FB8 0x00440F80
0x004407B8 [80] OBJ java/lang/ThreadGroup
0x004415D0 0x00440808 0x00440830 0x004415B0 0x004415C0
0x00440808 [40] OBJ [Ljava/lang/Thread;
0x00447AA8 0x004CFC10 0x004C7998
0x00440830 [32] OBJ [Ljava/lang/ThreadGroup;
0x00441730
0x00440850 [32] CLS java/util/Comparator
0x0075DA00
0x00440870 [32] CLS java/lang/String$CaseInsensitiveComparator
0x00440890 [32] OBJ java/lang/String
0x004408B0
0x004408B0 [112] OBJ [C
0x00440920 [32] OBJ java/lang/String
0x00440940
0x00440940 [112] OBJ [C
0x004409B0 [32] OBJ java/lang/String
0x004409D0
WebSphere Application Server V7
Announcement Workshop 2008
# 68
© IBM Corporation.
Heapdumpの出力例です。デフォルトの出力方式はバイナリですが、テキスト形式で出力する
ことも可能です。メモリ上のオブジェクトと参照元のオブジェクトがツリー構造で表示されています。
Java Diagnostics Guide 6 - Environment variables and Heapdump
http://publib.boulder.ibm.com/infocenter/javasdk/v6r0/index.jsp?topic=/com.ibm.java.doc.
diagnostics.60/diag/tools/heapdump_env.html
68
Summary
WAS
WAS V7
V7 W/S
W/S
Java EE 5
EoDを目標に仕様策定
オープンソースフレームワークの良い部分を取り入れている
EJB3.0
アノテーションベースでのコーディングが可能
実装の際の負荷が軽減されている
DI / AOPなどの機能が追加
JPA
EJB3.0で独立した仕様として策定
オープンソースフレームワークHibernateに似たO/Rマッピング方式を採用
Java SE 6
WAS V7のJDKはJava SE 6の仕様に準拠
ランタイムはパフォーマンス面でのいくつかの改善がなされている
基本機能はIBM JDK 5を踏襲
WebSphere Application Server V7
Announcement Workshop 2008
# 69
© IBM Corporation.
69
Reference
WAS
WAS V7
V7 W/S
W/S
WebSphere Application Server V7 - InfoCenter
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp
WAS V6.1 Feature Pack for EJB 3.0 ワークショップ資料
http://www.ibm.com/developerworks/jp/websphere/library/was/was61_ejb3fep_ws/
Java Diagnostics Guide 6
http://publib.boulder.ibm.com/infocenter/javasdk/v6r0/index.jsp
IBM Education Assistant - IBM WebSphere Application Server Version 7
http://publib.boulder.ibm.com/infocenter/ieduasst/v1r1m0/index.jsp?topic=/co
m.ibm.iea.was_v7/plugin_coverpage.html
WebSphere Application Server V7
Announcement Workshop 2008
# 70
© IBM Corporation.
70