websphere application server v6 アドバイザー認...

1

IBM Software Group

®

WebSphere Application Server V6 アドバイザー認定試験対策テキスト

WebSphere Application Server V6 対応版

WebSphere Application Server V6 アドバイザー試験対策教材

2005年 4月第1.1版発行

編集・発行日本アイ･ビー･エム株式会社ソフトウエア事業

©Copyright IBM Japan, Ltd. 2005

All Rights Reserved. Printed in Japan.

日本アイ･ビー･エム株式会社の文書による同意なく本製品およびテキストの一部または全部の無断転載、無断複

写することを禁止いたします。

本テキストの内容は予告なく変更されることがあります。

2

IBM Software Group | WebSphere software

目次

1. WebSphere V6 アドバイザー試験概要

2. WebSphere Application Server V6 概要

3. J2EEの基礎知識

4. J2EE1.4の新機能

5. WebSphere Application Server の管理

6. アプリケーションの管理

<memo>

3


1． WebSphere V6 アドバイザー試験概要

<memo>

4


WebSphere V6 アドバイザー試験概要

【試験名称】 WebSphere Application Server V6 アドバイザー

【試験時間】 1時間、全40問

【試験料金】 10,000円

【出題形式】コンピューターでの出題、全て選択問題

【合格ライン】60%以上の正解で合格

【出題内容】

J2EE1.4に関する基礎知識

WebSphere Application Server V6 製品概要

WebSphere Application Server V6 導入と構成・管理における基礎知識

【案内URL】

http://www-6.ibm.com/jp/software/websphere/wasgm/system_1.html

WebSphere Application Server V6 アドバイザー試験は、WebSphere Application Serverの基礎知識を問

うエントリー向けの試験で、日本国内限定の資格となります。

IBMのWebSphere認定試験としては、アドバイザーの他に、WebSphere Application Server V5.0 認定シ

ステム・アドミニストレーター Basic と、WebSphere Application Server V5.0 認定システム・アドミニストレ

ーター Advanced の資格があります。こちらはワールドワイドで共通の資格となります。2005年4月現在、

この資格のWebSphere V6 対応版はまだ出ておりません。

試験範囲としては、V5アドバイザーで必要であった開発ツール(WebSphere Studio)についての知識が不

要となりました。V6アドバイザーでは、J2EE1.4に関する基礎知識と、WebSphere Application Server V6

の基礎知識を問う資格となっています。

WebSphere Application Server については、製品概要・導入・構成・運用管理における幅広い範囲から

出題されますので、実際にWebSphere Application Serverをご使用になられている方も、この対策本や技

術資料等を通して、製品全体の知識を再度確認されることをお奨めいたします。

5


2． WebSphere Application Server V6 概要

<memo>

6


WebSphere Application Server (WAS) とは？

Webサーバー（HTTPエンジン）

静的コンテンツ（HTML/画像)

Webサーバー（HTTPエンジン）

Webアプリケーションサーバー・トランザクション管理・データベース接続・セッション管理・セキュリティー・メモリー管理 etc ・・・

アプリケーション（サーブレット/JSP/EJB）

Webサーバー Webアプリケーションサーバー

サーバーサイドJavaの実行環境

CGI,ASP,PHP

情報発信や情報検索中心決まったページがかえってくるだけ

データベースにアクセスしたり、トランザクション処理ができる拡張性に優れ、大量アクセスにも耐えられるJavaだとポータビリティも安心

WebSphere Application ServerはIBMが提供するWebアプリケーション・サーバーです。Webサーバー

（HTTPサーバー）ではありません。ブラウザーに対し、決められた静的コンテンツを発信するだけのWeb

サーバーと違い、データベースに接続したり業務ロジックを実行したりしながら動的なページを返すこと

ができます。

Webアプリケーション・サーバーはサーバーサイドJavaの実行環境を提供し、高パフォーマンスで拡張性

に優れたサイト構築を可能にします。またデータベース接続のパフォーマンスを上げるための機能やトラ

ンザクション管理、セッション管理、セキュリティといったアプリケーションを構築するにあたって必要とな

るローレベルの処理をあらかじめミドルウエアとして提供します。

7


WebSphere Application Server (WAS) の仕組み

WebサーバーWebサーバー

(例:IHSなど）

Plug-In

WebSphere Application ServerWebSphere Application Server

http/https

アプリケーションサーバー

Servlet JSP EJB

Webコンテナ EJBコンテナ

XML構成ファイル

XML構成ファイルサーバー管理情報を

保管するファイル

Database

①Webサーバー ②アプリケーションサーバー ③データベース

クライアント HTML

画像

Webアプリケーションで受けた要求をアプリケーションサーバ

ーへ転送

※IHS:IBM HTTP Server

DB2、 Oracle、SQL Server、Cloudscape、Informix サポート

WebSphere Application Server (WAS)を使用するシステムは通常3つの層から成りたっています。

1番目がブラウザーやクライアントからのリクエストを受け付ける部分であるWebサーバーです。Webサー

バーにはプラグインが組み込まれています。これにより、受けたリクエストがバックエンドにあるアプリケ

ーション・サーバーで処理すべきもの（ServletやJSPなど）であれば処理を後ろに転送します。受けたリク

エストがHTMLや画像といったWebサーバーで処理できるものであればその場で応答が返されます。

WASではWebサーバーとしてIBM HTTP Server (IHS)が同梱されています。

2番目の層がWebアプリケーション・サーバーの部分です。ここではServletやJSP,EJBといったサーバー

サイドJavaのプログラムを実行します。これらのプログラムは必要に応じてバックエンドにあるデータベー

スにアクセスをします。このデータベースが3番目の層になります。WebSphere Application Server V6で

は、DB2© 、Oracle© 、SQL Server©、Cloudscape© 、Informix© といった幅広いデータベースをサポート

しています。

WebSphere Application Serverの構成情報はXMLで記述されたファイルに保管され、必要に応じてプログ

ラムから参照されます。

8


WebSphere Application Server V6 ラインナップ

その他のファミリー

WebSphere Business Integration - Server Foundation (WBI-SF)• WAS V5.0 Enterpriseエディションの後継製品

• ワークフロー機能

WebSphere Extended Deployment (XD)• 仮想化、動的な拡張性、高パフォーマンス

WAS-ExpressWAS-Express

ISVソリューションの基盤

WAS (Base) WAS (Base)

WAS Network Deployment (ND)WAS Network Deployment (ND)

シングルサーバーの実行環境を提供

複数サーバー分散環境で、クラスタリング、HA(高可用性)機能、管理機能を提供

WindowsWindows LinuxLinux AIXAIX SolarisSolaris HP-UXHP-UX OS/400OS/400 z/OSz/OS®® ®® ®® ®® ®® ®®

WebSphere Application Serverには3つのエディションがあります。下から順番にWebSphere Application

Server Express (WAS-Express), WebSphere Application Server (WAS-Base), WebSphere Application

Server Network Deployment (WAS-ND)となります。以前のWebSphere Application Server Enterprise

(WAS-Enterprise)は、V5.1からWebSphere Business Integration - Server Foundation (WBI-SF)に名前が

変更されました。

WAS-Expressは最もエントリーレベルに位置し、小規模なWebアプリケーションやイントラネットの部門サ

ーバーの構築、またソリューション・パッケージのベースとしての使用に適しています。

WAS-Baseはシングル・サーバー構成用のパッケージです。WAS-Expressは2CPUまでのサポートとなり

ますが、BaseではCPU数に制限がありません。

WAS-NDは複数サーバーでのクラスタリング構成が可能な本番業務用のパッケージです。HA機能や統

合された管理機能を提供します。

また、WebSphereファミリーとして、WAS-Enterpriseの後継製品であるWebSphere Business Integration -

Server Foundation (WBI-SF)と、WebSphere Extended Deployment (WebSphere XD)があります。

WBI-SFは、J2EE仕様を拡張するワークフロー機能を提供します。

WebSphere XDは、アプリケーション・サーバーの仮想化、動的な拡張機能を提供し、大規模な分散シス

テムに適しています。

9


WAS V6 エディション間の違い

・シングルサーバー構成

・ 2CPUまでサポート

・複数サーバー、クラスター構成

・ Edge Components同梱

ロードバランサー

キャッシング・プロキシー

WAS-Express

WAS (Base)

WAS-ND

・シングルサーバー構成

・CPU数の制限無し

○

○

○

IHS同梱

プラグイン

○

○

○

WebSphere Extensions

×××○2CPUまでWAS-Express

×××○無制限WAS (Base)

○○○○無制限WAS-ND

キャッシング・プロキシー


クラスター構成

J2EEE1.4フルサポート

サポートCPU数

全てのエディションにおいて

・J2EE1.4フルサポート

・WebSphere Extensions機能の提供

・IHS、プラグイン同梱

V5からの変更点

各エディションの違いについて簡単に整理すると以下に様になります。

V6では、全てのエディションにおいて、J2EE1.4をフルサポートします。（V5のExpressではEJBのサポート

がありませんでした。）また、V5ではEnterprise版でのみ提供されていたJ2EEに対する拡張機能

(WebSphere Extensions)をExpressからサポートするようになりました。

ExpressとBaseは、どちらもシングルサーバー構成のサポートとなりますが、Expressでは2CPUまでといっ

た制限があります。

NDでは複数サーバーのクラスター構成をサポートし、またロードバランサーやキャッシング・プロキシー

機能を提供するEdge Componentsを同梱しています。

WAS-Enterprise版で提供されていたJ2EEワークフロー機能は、WBI-SFに引き継がれました。

これらエディションの違いについては出題頻度が高いため、表をよく覚えておくと良いでしょう。

10


Edge Componentsって？


Webサーバー X 2

キャッシングプロキシー

最適サーバーに割り振り

障害発生時は割り振り停止

1．ロードバランサー

2．キャッシング・プロキシー

Internet

Internet

WAS-ND版

WebSphere Application Server Network Deployment（ND) に同梱されるEdge Componentsは、ロードバ

ランサーとキャッシング・プロキシーの機能を提供します。

ロードバランサーは、複数のWebサーバーに処理を割り振る機能を提供します。ただ単純に割り振るだ

けでなく、レスポンスタイムやコネクション数などWebサーバーの負荷を見ながら、一番負荷の少ないサ

ーバーへの割り振りを行います。また、障害を検知した場合には自動的にそのサーバーへの割り振りを

停止し、障害から回復した場合に再度割り振りを開始します。その他にも負荷が限界を超えた場合に

Sorryサーバーへ割り振り「ただいま大変こみあっております」といったメッセージを出したり、ある決めら

れた時間になると「ただいまメンテナンス中です」といったメッセージを出すこともできます。

キャッシング・プロキシーは頻繁にアクセスされるページをあらかじめキャッシュサーバーにためておき、

そのサーバーからレスポンスを返す機能です。Webサーバーやアプリケーション・サーバーへの負荷を

軽減し、大幅なパフォーマンス向上を図ることが可能です。

11


練習問題

② WebSphere Application Server V6 Network Deployment の特徴を２つ選びな

さい。

A. J2EEに準拠するWebアプリケーション・サーバーである

B. WebサーバーがWebコンテナを提供し、WebSphere Application ServerはEJBコンテナのみを提供する

C. 基本的に、Webサーバーが動的コンテンツを、WebSphere Application Serverが静的コンテンツを提供する

D. トランザクションやセッション管理といったWebアプリケーションで必要となる機

能を提供する

① WebSphere Application Server V6について正しい説明を２つ選びなさい。

A. J2EE1.4フルサポート

B. シングル・サーバー構成

C. 複数サーバー分散環境でのクラスタリング

D. ワークフロー機能

<memo>

12


3． J2EEの基礎知識

<memo>

13


J2EEとは？

Javaプラットフォーム、3つのエディション

J2ME (Java 2 Platform, Micro Edition)

J2SE (Java 2 Platform, Standard Edition)

J2EE (Java 2 Platform, Enterprise Edition)

J2EE とは、Javaでエンタープライズ・アプリケーションを開発・配備

するために必要な仕様(API)を標準として備えたもの

Servlet, JSP, EJB, JMS, JTA, JNDI, etc

業界全体にわたる合意

各仕様はJCP (Java Community Process)にて決定

2003年11月にJ2EE1.4がFinal Releaseに

Javaのプラットフォームには3つのエディションがあります。

●J2ME (Java 2 Platform, Micro Edition)・・・組み込み機器向けに絞り込んだ機能

●J2SE (Java 2 Platform, Standard Edition)・・・基礎となる標準的な機能

●J2EE (Java 2 Platform, Enterprise Edition)・・・エンタープライズ向けの拡張機能

WebSphere Application Serverは、エンタープライズ・アプリケーションを構築するためのJ2EE (Java 2 Platform, Enterprise Edition)に準拠しています。

J2EEの仕様は、JCP (Java Community Process)というオープンなプロセスを経て決定されます。このコミュニティには、IBMやSun Microsystems、Oracleを始めとして数多くのベンダーが参画しています。J2EEの仕様は、特定の1社が決定するわけではなく、コミュニティに参画する業界全体の合意に基づいて作成されているのです。

JCPのメンバーは、Javaに関する新規の仕様の開発および既存の仕様の変更について、自由にリクエストを上げることができます。このリクエストは、JSR（Java Specification Request）と呼ばれ、それぞれ番号をつけて管理されています。このJSRはJCPに提出されて承認されると、専門化グループにより仕様化され、Draftとして一般に公開されます。このDraftはJCPおよび一般のメンバーによるレビューを受けて改訂され、最終的にはFinal Releaseとなり、リファレンス実装（Reference Implementation）が作成されます。最後に、JCPの委員会において承認されたJSRは、公式な仕様となり、保守（Maintenance）期間に入ります。

J2EE1.4は、2003年11月にFinal Releaseとなっています。J2EE1.4の特徴や新機能については、後ほどのセクションでご紹介します。

14


J2EEプラットフォームの階層構造

クライアント・サイドプレゼンテーション層

・アプレット・コンテナ・アプリケーション・クライアント・コンテナ

サーバー・サイドプレゼンテーション層

ビジネスロジック層データ層

・Webコンテナ・EJBコンテナ・データベース/EIS

① ② ③

④

http://java.sun.com/j2ee/1.4/docs/tutorial/doc/

J2EEの実行環境は階層構造を採用しており、以下の4層からなります。

●クライアント・サイド・プレゼンテーション層・・・アプレット・コンテナやアプリケーション・クライアント・コン

テナを提供

●サーバー・サイド・プレゼンテーション層・・・Webコンテナを提供

●ビジネスロジック層・・・EJBコンテナを提供

●データ層・・・データベースやEIS

JSPやServletはWebコンテナで、EJBはEJBコンテナで実行されます。

WebSphere Application Server V6の製品パッケージには、クライアント実行環境も含まれていますが、

WebSphere Application Serverのアプリケーション・サーバー・プロセスは、サーバーサイド・プレゼンテー

ション層であるWebコンテナと、ビジネスロジック層であるEJBコンテナを提供します。（図の②と③）

15


Webアプリケーションの作成手順（概要）

1. Webアプリケーション（Servlet, JSP, EJB等）のコード記述

2. クラスファイルの作成（コンパイル）

3. Deployment Descriptor（DD、配備記述子）の作成

4. パッケージング（EARファイル、もしくはWARファイルの作成）

5. Webアプリケーション・サーバーに配備（Deploy）

6. テスト（必要に応じて、デバッグ、修正）

Webアプリケーション作成手順の概要を確認しましょう。

1. WebアプリケーションのコンポーネントとなるServletやJSP、EJB等のコードを記述します。

2. ServletやEJBのソースコードをコンパイルし、クラスファイル作成します。（JSPについてはコンパイル

不要）

3. Deployment Descriptor (DD, 配備記述子)と呼ばれるXML形式の定義ファイルを作成します。

4. J2EEのアプリケーション形式（EARファイルまたはWARファイル）にパッケージングします。

通常ここまでは開発ツールを用いて行います。（エディタやJDKを用いた開発も可能です）

5. 作成したJ2EEアプリケーションをWebアプリケーション・サーバーに配備（Deploy）します。アプリケーシ

ョンがコンテナに配備され、開始されると、クライアントからのリクエストを処理できるようになります。

6 必要に応じてデバッグ・修正を行います。

開発ツールによっては、内蔵のテスト環境を持っており、サーバーに配備しなくても単体テストができるも

のもあります。(統合開発ツールであるIBM Rational Application Developerは、WebSphere Application

Serverのテスト環境を内蔵しています)

16


Servletとは？

クライアントと対話型処理を行うサーバープログラム

リクエストごとにservice()メソッドが呼び出され、マルチスレッドで動く

初期処理(init)

サービス処理(service)

終了処理(destroy)

リクエスト

レスポンス

サーブレット起動

サーブレット消滅

WAIT

処理の流れ

serviceメソッド

doGetメソッド

doPostメソッド

HTTP GET要求で受けた場合

HTTP POST要求で受けた場合

HTTP GET要求：フォームでMETHOD=“GET”を指定した場合URLから直接サーブレットを呼び出した場合

HTTP POST要求:フォームでMETHOD=“POST”を指定した場合

ここからはJ2EEの主要なAPIを見ていきましょう。

Servletはアプリケーション・サーバー上のWebコンテナで実行され、動的コンテンツをクライアントに返す

ためのWebコンポーネントのひとつです。(後述のJSPも同様にWebコンポーネントのひとつです。) Servlet

はWebクライアントからHTTP/HTTPSプロトコルでリクエストを受け、何らかの処理を行ってWebクライア

ントにレスポンスを返します。サーブレットは最初のリクエスト時に1回だけインスタンス化され、あとはメ

モリー（JVM）に常駐します。

最初のリクエスト時にサーブレットがロードされますが、このときに1回だけ呼び出されるのがinit()メソッド

です。これはサーブレットの初期化処理を行います。次にクライアントがサーブレットを呼び出す度に

service()メソッドが呼びされます。ここにサーブレットで処理したい内容の本体を記述します。最後にサー

ブレットがサーバーからアンロードされる時に一度だけ呼び出されるのがdestroy()メソッドです。アプリケ

ーションの後処理などがあればここに記述します。

また、service()メソッドはクライアントの要求に応じてdoGet()メソッドやdoPost()メソッドを呼び出します。

HTTPのGET要求が来た場合はdoGet()、POST要求が来た場合はdoPost()で記述された内容が処理さ

れます。

17


セッション管理概要

Servlet A

Servlet B

HttpSession

SessionID=XXX

SessionID=XXX

SessionID=XXX

ログイン画面

ログイン成功画面

商品選択画面

HTTPはステートレスなプロトコル

クライアントが送る一連のリクエストをトラッキングするための仕組み⇒セッション管理セッションIDを割り当て、CookieまたはURL再書き込みでセッションIDを送受信

SessionID=XXX

SessionID=XXX

SessionID=XXX

初回リクエスト時、SessionIDが戻る以降のリクエストではSessionIDを送る

セッションオブジェクト獲得

セッションオブジェクトへ値を格納or取得

セッションマネージャー

HTTPプロトコルはストレートレスなプロトコルです。状態を維持できないため、クライアントとサーバーの

メッセージ送受信1往復で処理が終わるという特徴があります。つまり同じクライアントとサーバーのやり

とりであっても1回1回が違う接続となるため、サーバーはアクセスしてきたクライアントが前回と同じクラ

イアントであるか識別ができないのです。そこでクライアントとサーバーのやり取りの関連性を持たせる

方法としてセッション管理というものがあります。これを実現するにはHttpSessionオブジェクトを使用しま

す。サーブレットはクライアントから要求がきたら、HttpSessionオブジェクトを生成し、クライアント情報を

格納します。このHttpSessionオブジェクトを生成すると暗黙のうちにセッションIDというユニークな文字列

が生成されます。このセッションIDをCookieとしてクライアントに送信することでクライアントとサーバーを

関連付けします。Cookieをサポートしていないブラウザーの場合はURL再書き込み（呼び出すServletの

リンク先URLにセッションIDをパラメータとして付加）を使って関連付けをします。（WebSphere Application

Serverでは、その他SSL IDでのトラッキングもサポートしていますが、CookieやURL再書き込みと併用す

ることをお勧めしています。)

HttpSessionオブジェクトはサーバーのJVM上に一定期間保管されます。HttpSessionオブジェクトのサイ

ズが大きくなったり、保存するセッション・オブジェクトの数が大きくなるとメモリーを逼迫しますので、セッ

ションサイズを必要以上に大きくしない、不要になったHttpSessionオブジェクトは破棄するなど、パフォー

マンスに考慮して設計する必要があります。

複数アプリケーション・サーバーがある場合のセッション管理については、WebSphere Application Server

の管理のセクションでご紹介します。

18


JSP (JavaServer Pages) とは？

サーバー・サイドでのスクリプティング技術コンテンツを動的にインクルードしてページを生成 HTML/XMLファイルにJSPタグでJavaのコードを埋め込む JSPはサーブレットに変換されてWebコンテナー上で実行される

処理の流れ

JSPファイル

JSPファイル

静的コンテンツ

静的コンテンツ

Javaソー

ス（動的）

Javaソー

ス（動的）

クライアント画面

1.リクエスト

2.JSPファイルがリクエストされるとJSPプロセッサーが処理開始

2.1初回リクエストであればJSPファイルを動的コンテンツとJavaソースに分解

2.2 コンパイルしてクラスファイル生成

3.JSPサーブレットは動的コンテンツに処理結果（Javaの処理結果）をインクルードしながらレスポンスを生成

4.クライアントへのレスポンス

生成されたクラスファイルは一時ディレクトリに保管され再利用される

JSPはサーバーサイドでのスクリプティング技術です。

JSPの実体はHTML形式で作成されたコンテンツの中にJSPの仕様として定められた独自のタグ（JSPタ

グ）を記述したコンテンツです。JSPファイルをサーバーサイドで実行させその結果、静的なHTMLタグと

動的に作成されたHTMLタグを組み合わせてレスポンスを返します。

JSPファイルに対する要求はWebサーバーまたはアプリケーション・サーバーが受け取ります。要求元は

ブラウザーの場合もあればサーブレットの場合もあります。要求はまずJSPコンテナ（Webコンテナ）に送

信されます。次のような場合にはJavaに変換され、コンパイルされてサーブレット・クラスとなり、メモリー

上にロードされインスタンスが作成されます。

●該当するJSPのインスタンスがメモリー上に存在しない

●該当するJSPソースがコンパイル済みのバージョンより新しい

一度メモリー上にインスタンスが生成されるとその後のリクエストはこのインスタンスにより処理されます。

WebSphere Application Server では、アプリケーションを導入するときに、JSPをプリコンパイルすることも

可能です。

19


JSPの基礎

JSPはHTMLの中にタグを記述

ディレクティブ・・・<%@ %>• pageディレクティブでは、インポートするクラス、contentType、pageEncoding、

sessionを使用するかどうか等を指定。

宣言・・・<%! %>• 宣言しなくても使える暗黙オブジェクトも有る

• オブジェクトのスコープは、application・session・request・pageの4種類

スクリプトレット・・・<% %>• ここにJavaのコードを記述

式・・・<%= %>• 実行結果を返す式を記述

アクションタグ・・・<jsp: />• フロー制御やBeanにアクセスするタグ

カスタムタグを作ることも可能

JSP 2.0で新しく提供されたEL, JSTLについては後述

JSPで使用できるタグには以下のようなものがあります。

<%@ %>ディレクティブ：pageディレクティブでは、インポートするクラス、エンコード方式、セッションを

使用するかどうかなどJSPプログラム全体に関する定義を行います。暗黙的にjava.lang.*,

javax.servlet.*, javax.servlet.jsp.*, javax.servlet.http.* をインポートし、HttpServletを継承

しています。JSPではデフォルトでセッションが有効になっていますが、パフォーマンスを考慮

して無効にしたい場合はここのsession属性で指定します。

<%! %>宣言：ページで参照される変数、メソッドを宣言します。これらは生成されるサーブレッ

トのクラス変数、メソッドになります。JSPでは宣言しなくても使用できる暗黙オブジェクトが

存在します。(request, response, session, outなど)

<% %>スクリプトレット：クライアントのリクエストを処理するJavaコードを記述します。

<%= %>式：Javaの変数式を記述します。変数式の評価結果が文字列に変換されてHTML/XMLフ

ァイルの該当箇所にインクルードされます。

<jsp：xxx />標準アクション：xxxで指定された処理を実行します。通常、処理はスクリプトレッ

トで記述しますが、使用頻度の高い処理を簡単に利用できるように提供されています。例えば

JavaBeansをアクセスするためのタグやフロー制御（forwardやinclude）を行うタグなどが用意されて

います。

20


EJB (Enterprise JavaBeans) とは？

サーバーサイドJavaを部品化（コンポーネント化）するためのAPI JavaBeansとの大きな違いはEJBコンテナで実行される点

コンテナがトランザクション制御やセキュリティ管理、ライフサイクル管理等のサービスを提供

EJBの呼び出しには、IIOPプロトコルが使用される

EJBにはSession Bean, Entity Bean, Message-Driven Beanの3種類がある

セッションを管理するSession Bean

データを永続化するEntity Bean

非同期メッセージの到着をトリガーに起動するMessage-Driven Bean

Session Bean Message-DrivenBean

EJB

Container-ManagedPersistence

Entity Bean

Bean-ManagedPersistence Stateless Stateful

EJBとはサーバーサイドJavaをコンポーネント化するためのAPIで、ビジネスロジックを実装します。作成

されたEJBコンポーネントはアプリケーション・サーバーのEJBコンテナ上で実行されます。EJBコンテナ

がトランザクション制御やセキュリティ管理、ライフサイクル管理といったシステムレベルのサービスを提

供しますので、EJB開発者はこれらの処理をコンテナにまかせて、ビジネスロジックに集中することがで

きます。またEJBの呼び出しには、ServletやJSPと違って、IIOPプロトコルが使用されます。（Servlet, JSP

ではHTTPプロトコルを使用。）EJBは分散トランザクションをサポートし、アプリケーション・サーバー

(JVM)をまたがった呼び出しにおいても1つのトランザクション・スコープ内におさめることができます。

EJBにはSession Bean, Entity Bean, Message-Driven Beanの3種類があります。

セッションを管理するSession Beanには、状態を持つStateful Session Beanと、状態を持たないStateless

Session Beanの2種類があります。

データを永続化するEntity Beanには、永続性をコンテナにまかせるCMP (Container-Managed

Persistence) と、Beanで制御するBMP (Bean-Managed Persistence)の2種類があります。

非同期メッセージの到着をトリガーに起動するMessage-Driven Beanは、EJB2.0（J2EE1.3）で新しく追加

されたBeanになります。

21


JMS (Java Message Service) とは？

非同期メッセージングを扱うためのAPI

MOM（メッセージング指向ミドルウェア）に接続する

2種類のモデル

Point to Point (PTP)

Publisher

Publish/Subscribe (Pub/Sub)Subscriber

SubscriberTopic

JMSクライアント

JMSクライアント

Sender Receiver

Queue

JMSクライアント JMSクライアントJMSプロバイダ

JMSプロバイダ

JMSとは、Javaで非同期メッセージを扱うためのAPIです。WebSphere Application Serverが提供するメッ

セージング・エンジン(ME)やWebSphere MQといったMOM（メッセージング指向ミドルウェア）にアクセスす

るためのAPIを規定しています。

JMSには2種類のモデルがあり、１つはPoint to Point (PTP)、もう１つはPublisher/Subscriber (Pub/Sub)

といいます。

PTPは宛先をQueueと呼び、メッセージを生成する側をSender、メッセージを消費する側をReceiverと呼

びます。SenderとReceiverは1対1の関係で、クライアントは特定のQueueに対してメッセージを送信し、そ

のメッセージをJMSクライアントがQueueから受信します。

Pub/Subは、宛先をTopicと呼び、メッセージを生成する側をPublisher、消費する側をSubscriberと呼びま

す。Subscriberは自分が受信したいトピックを登録します。PublisherがメッセージをTopicに送信すると、

そのTopicを登録している不特定多数のSubscriberにメッセージが送信される仕組みです。

22


Deployment Descriptor とは？

Deployment Descriptor （DD, 配備記述子）とは、J2EEの各モジュールでの設定情報を表す

各モジュール毎に決められた形式のDDが必要

XML文書の形式で表記

Webモジュールには web.xml が必要。サーブレットの登録や初期設定、URLとのマッピング、

認証情報の設定などを行う

EJBモジュールには ejb-jar.xmlが必要。Beanの登録やインターフェースの指定、セッションや

トランザクションのタイプなどを指定する

コンテキストルートの設定は、アプリケーションDD(application.xml)で行う

web.xmlの例（抜粋）

<?xml version="1.0" encoding="UTF-8"?><web-app xmlns="http://java.sun.com/xml/ns/j2ee"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd" version="2.4">

<web-app><servlet>

<servlet-name>Hello Servlet</servlet-name> 任意のサーブレット名<servlet-class>Hello</servlet-class> サーブレットのクラス名

</servlet> <servlet-mapping>

<servlet-name>Hello Servlet</servlet-name><url-pattern>/hello</url-pattern> URLパターン（このURLで呼び出される）

</servlet-mapping></web-app>

Deployment Descriptorとは、各モジュールで必要となる設定情報を表すXML形式のファイルになります。

Webモジュールにはweb.xmlという名前のDeployment Descriptorが、EJBモジュールにはejb-jar.xmlとい

う名前のDeployment Descriptorが必要です。また、アプリケーション全体（EARファイル単位）として、

application.xmlという名前のDeployment Descriptorも必要です。各モジュールで必要となるDeployment

Descriptorの名称は決まっています。

Deployment Descriptorで設定できる内容には以下のものがあります。（抜粋）

アプリケーションのDD（application.xml）

コンテキスト・ルート、EARに含まれるモジュール等

WebモジュールのDD（web.xml）

サーブレットやJSPの登録、URLとのマッピング、初期化パラメーター、参照、セキュリティ等

EJBモジュールのDD（ejb-jar.xml）

Beanの登録、ホーム／リモート・インターフェースの指定、パーシスタンスの指定等

23


J2EEのパッケージング

Webアプリケーションは、EAR (Enterprise ARchive )ファイル、またはWAR (Web ARchive) ファイルにパッケージング

モジュール毎に設定情報を表すDeployment Descriptor が必要

Client Class

クライアント･モジュール

.JARファイル

DD = Deployment Descriptor、配備記述子

J2EE アプリケーション

.EARファイル

DD

application.xml

HTML, GIF, etc.

Servlet JSP

Webモジュール

.WARファイル

web.xml

EnterpriseBean

DD

EJBモジュール

.JARファイル

ejb-jar.xml application-client.xml

ResourceAdapter

リソース・アダプター・モジュール

.RARファイル

ra.xml

DDDD DD

各アプリケーション・コンポーネント（Webコンポｰネント、EJBコンポーネント）を実行環境であるアプリケーション・サーバーのコンテナ上で動かすためには、J2EEの仕様に従ってパッケージングし、パッケージングしたものをコンテナ上に配備（デプロイ）する必要があります。J2EEアプリケーションでは、各モジュールと前述のDeployment Descriptor（配備記述子）を一緒にアーカイブし、拡張子が.EARと付くファイルにパッケージングします。EARファイルの中で各モジュールとDeployment Descriptorを配置する場所は仕様で決まっています。

24


MVCモデルとは？

WebアプリケーションをModel、View、Controllerの役割に分割

Controller（全体制御）： Servlet

Model（ビジネスロジック）： EJBまたはJavaBeans

View（表示）： JSP

ビジネスロジックの開発者（Javaプログラマ）と画面のデザイナーの分離が可能

プログラムのコンポーネント化により、保守性や再利用性を高める

Controller：Servlet

View：JSP

Model：EJB/

JavaBeans

入力

出力Webブラウザー

ロジックの実行依頼

処理結果

表示処理依頼

MVCモデルとはWebシステムを構築する際に使用されるプログラミング・モデルです。処理をそれぞれ独

立したコンポーネントに分割することによって、独立性を高め、開発生産性を向上させるのが目的です。

また独立性が高まることによって、各コンポーネントが保守がしやすくなるというメリットもあります。

MVCモデルのMはModel、VはView、CはControllerをさします。Webクライアントからの要求はController

であるServletにより処理されます。Servletは業務ロジックを担当するModelと画面生成を担当するJSPの

橋渡しを担当します。ModelはJavaBeansやEJBで実装され、データベースや他システムと通信しながら

業務処理を行います。ViewはJSPで実装され、ModelであるJavaBeansやEJBで処理された結果を元に

動的にWebページを作成し、クライアントに返します。

25


練習問題

④J2EEアプリケーションのパッケージングについて、間違っている記述を１つ選

びなさい。

A. IBMが仕様を決定している

B. Sun Microsystemsが仕様を決定している

C. エンタープライズ・アプリケーションを構築するために必要なAPIをまとめたもの

D. WebコンテナではServletとEJBが実行される

③J2EEについて正しい記述を１つ選びなさい。

A. J2EEアプリケーションはEARファイルにパッケージングする

B. WebモジュールにはServletやJSPが含まれる

C. 各モジュールにはDeployment Descriptorと呼ばれるファイルが必要である

D. Deployment Descriptorの名前と配置場所は開発者が任意に決めることができる

<memo>

26


練習問題

⑥JSPの説明について誤った記述を１つ選びなさい。

A. Webブラウザー上で稼動するプログラムである

B. クライアントからリクエストが来る度にservice() が実行される

C. MVCモデルにおけるModelの役割を果たす

D. セッションを管理することができる

⑤Servletの説明について正しい記述を２つ選びなさい。

A. HTML形式のコンテンツの中にJSPのタグを記述する

B. コンパイルされるとServletとして実行される

C. WebSphereではデプロイ時に事前コンパイルも可能

D. JSPではセッションを管理することができない

<memo>

27


4． J2EE1.4の新機能

<memo>

28


J2EE1.4とは？

J2EEの歴史

J2EE1.2 1999年12月

J2EE1.3 2001年 7月

J2EE1.4 2003年11月

J2EE1.4の主なAPI• Servlet 2.4• JSP 2.0• EJB 2.1• JCA 1.5• JDBC 3.0• JMX (Java Management Extensions) 1.1• Webサービス (JAX-RPC, Web Services for J2EE) など…

WAS V4

WAS V5

WAS V6

J2EE1.4は2003年11月にFinal Releaseとなりました。WebSphere Application Server V6は、このJ2EE1.4

に準拠しています。

J2EE1.4には、以下に示す代表的なAPIが含まれています。

JSP 2.0

Servlet 2.4

EJB 2.1

JMS 1.1

JDBC 3.0

JCA 1.5

JMX 1.1

J2EE Management (JSR-77) 1.0

J2EE Deployment (JSR-88) 1.1

Web Service for J2EE (JSR-109) 1.1

JAX-RPC (JSR-101) 1.1

J2EE1.4の主な特徴は以下の通りです。

●JSPのバージョンが上がり、JSPの開発生産性が高くなったこと

●JAX-RPC, Web Services for J2EEといったWebサービス関連のAPIが新たに追加されたこと

●JMX (Java Management Extensions)を始めとして、システム管理のためのAPIが新たに追加されたこ

と

29


Servlet 2.4での新機能

Servlet 2.3からの大きな変更はない Servlet 2.4での主な新機能

Servlet 2.3から導入されたServlet Filterに対する機能拡張

Servlet 2.3から導入されたServletContextとHttpSessionリスナー機能を、Requestにも拡張

国際化機能の拡張

Servlet Filterとは

クライアントからのリクエスト(～2.3)やサーバー内部でのページ転送時(2.4からはINCLUDE, FORWARD, ERRORも対象)にフィルター処理を実行する

認証やロギング、データの圧縮処理などに活用

AccessReceiveServlet

IncludeServlet

ForwardServlet

2.3までのフィルター

(REQUEST)

INCLUDEフィルター

FORWARDフィルター

Webコンテナー

New

Newクライアント

ここからは、J2EE 1.4の中でも代表的なAPIである、Servlet、JSP、EJB、Webサービス関連APIの新機能

についてご説明します。

まずServletですが、J2EE1.4ではServlet 2.4が採用されています。Servlet 2.4では、Servlet 2.3からの大

きな変更はなく、Servlet 2.3で提供されたServlet Filterやリスナー機能、国際化機能についての拡張が

中心となっています。

ここでは、Servlet Filterについて簡単にご紹介します。

Servlet Filterは、Servlet 2.3から導入された機能で、2.4で機能拡張されました。Webアプリケーションにフ

ィルターを登録することにより，個々のServletやJSPに処理を分散させることなく，フィルターで統一的な

処理をすることが可能になります。フィルターは、該当するServlet、JSPの実行前に呼ばれます。フィルタ

ーは複数登録することが可能で、様々な処理を行うフィルターを同居させることができます。

例えば、リクエストのアクセス制御を行ったり、ログを収集したり、レスポンスを返す前にデータのフォー

マット変換や圧縮処理を行ったりすることができます。メリットとしてはWebアプリケーションの本体を修正

することなく、処理を追加したり取り外したりできることがあげられます。

30


JSP 2.0での新機能

EL (Expression Language) とは

JSPからJavaプログラミングコードの分離

従来のJSP1.2の式とは異なる文法による変数やオブジェクトへのアクセス方法

− ${ ～ } で表記例： ${item.price}

− JSP1.2までの式 (<%= ～ %>) と比較して、Javaを知らなくても理解しやすい

従来の表記例： <jsp:useBean id=“item” class=“Item” /><%=item.getPrice() %>

JSTL (JSP Standard Tag Library) とは

カスタムタグの標準ライブラリーを追加

Webアプリケーションに共通の汎用・頻出機能を実装

コーディングの削減、質の向上、業務ロジック作成に専念

xXMLファイルの操作を行うXML

コレクションの長さの取得や文字列操作を行う

データベースへアクセスし、SQLによる操作を行う

数字や日付などの書式、国際化対応のためのロケール設定などを行う

変数の設定、参照、また条件分岐やループ処理などの基本的な操作を行う

説明

fnFunctions

sqlSQL

fmtI18n

ccore

接頭辞ライブラリー

J2EE1.4では、JSPのバージョンが1.2から2.0と上がり、JSPの開発がより簡単になりました。ここではJSP

2.0の主な新機能であるELとJSTLについて簡単に解説します。

EL (Expression Language , 式言語) とは、JSP 2.0で新しく追加された、変数やオブジェクトにアクセスす

るための表記方法です。${～}で囲むのがELの表記法です。これをWebコンテナが検知して、処理を実行

します。

上記の例のように、例えば、itemオブジェクトのprice属性の値に対して、${item.price} という表記でアクセ

スすることができます。JSP 1.2までの式 (<%=～%>) を使用した属性値へのアクセスと比較して、Java言

語に精通していなくても直感的で分かりやすい文法になっています。従来の式で記述していた箇所でEL

を使用することができます。

ELを使用することにより、JSPページから式やスクリプトレットを削減することができ、JSPの特徴である

画面デザイナとJavaプログラマの分離を更に図ることができます。

ELにも11個の暗黙オブジェクトが用意されています。

JSTL (JSP Standard Tag Library) とは、カスタムタグのコレクションであり、Webアプリケーションに共通

の汎用・頻出機能をタグライブラリーとして標準化したものです。標準的な処理についてはこのタグライ

ブラリーを使うことによって、ユーザーのコーディング量の削減や品質の向上を期待することができます。

JSTLで使用できるタグライブラリーは、その機能から5種類に分類されています。例えばcoreタグライブ

ラリーは、変数を扱う一般的なタグや条件分岐・繰り返しを指定するタグなど、基本的なロジックを表すタ

グが集められています。またそれぞれのタグライブラリーで宣言するURIと接頭辞(prefix)については仕

様で決まっています。

31


EJB 2.1での新機能

EJB 2.0から大きな変更はない

EJB 2.1での主な新機能

Timer Service

• 設定したスケジュールに基づいてメソッドをコールバックさせる仕組み

• Stateful Session Bean以外のEJBコンポーネントで利用可能

• トランザクションをサポート

• 永続性をサポート

− アプリケーション・サーバーを再起動しても失われない

EJB QLの拡張

• EJB 2.0では定義されていなかったORDER BY節や集約関数をサポート

EJB 2.1は、EJB 2.0から大きな変更はありません。ここでは主な新機能のうち以下の2つをご紹介します。

Timer Serviceは、設定したスケジュールに基づいてメソッドをコールバックさせることができる、コンテナ

管理のサービスです。コールバックとは、一般に、呼び出し側が接続を一旦切断し、つぎに接続先から呼

び出し側を呼び出すことです。これをタイマーサービスにあてはめて考えると、EJBがタイマー・サービス

に対しタイマーの作成した時点で一旦終了します。そして、設定時間になると、タイマー・サービスがEJB

に実装されたejbTimeoutメソッドを呼び出す、という仕組みになります。

タイマーサービスは、特定の時間に実行したり、一定時間の経過後に実行したり、一定の時間間隔で実

行することが可能です。タイマーサービスは、Stateful Session Beanを除く全てのEJBコンポーネントで利

用できます。また、タイマーサービスはトランザクションをサポートしていますので、例えばトランザクショ

ンがロールバックした場合には、タイマー作成もロールバックされるようになっています。タイマーサービ

スは永続性をサポートしていますので、アプリケーション・サーバーを再起動した場合にもタイマーが失

われずにすみます。

EJB QL（EJB Query Language）は、Entity Beanの検索を行うfinderメソッドの実装方法についての標準

的な仕様を定めるために、EJB 2.0で新しく導入された機能です。それ以前のEJBでは、finderメソッドに

関する明確な規定がなく、EJBの可搬性に問題が生じることがしばしばありました。そこでEJB 2.0から

CMP Entity Beanを検索する標準的な機能としてEJB QLが定義されました。EJB QLはSQL-92をベース

としたQuery言語です。EJB 2.1では、新たにORDER BY節やAVG, MAX, MINといった集約関数をサポー

トするようになりました。

32


Webサービス

Webサービスとは？

インターネット標準技術を利用してソフトウェア・コンポーネントを遠隔呼び出し

• SOAP、WSDL、UDDI

Webサービスの相互接続性

Webサービスの標準化団体WS-Iが定めるWS-I Basic Profile

J2EE1.4ではWebサービスが必須の機能に

Web Services for J2EE• J2EE環境におけるWebサービスの開発、パッケージング、デプロイについて定義

JAX-RPC (Java API for XML-based RPC)• JavaプログラムでSOAPによるRPCを行う方法を定義

SAAJ (Soap with Attachment API for Java)• SOAPにメッセージを添付

JAXR (Java API for XML Registry)• UDDIレジストリなどのレジストリサービスにアクセスするためのJavaのAPI

Webサービスとは、インターネットの標準技術（SOAP, UDDI, WSDL）を用いて遠隔呼び出しが可能なソフ

トウェア・コンポーネントです。稼動するプラットフォームや言語には依存しません。

SOAP・・・Webサービスを呼び出すためのプロトコル。XMLベースのメッセージはSOAP Envelopeと呼ば

れ、ヘッダー情報のSOAP Headerと、メッセージ本体であるSOAP Bodyに分かれる。SOAPでは実際のト

ランスポート層プロトコルについては規定しておらず、特定のプロトコルには依存しない。HTTP, JMS,

IIOPといったプロトコルが利用可能です。

WSDL・・・Webサービスのインターフェース定義やサービス内容をXML形式で記述したもの

UDDI・・・Webサービスを登録・検索するためのレジストリ

Webサービスの相互運用性を高めるために、Webサービスの標準化団体であるWS-I (Web Services

Interoperability Organization )が、WS-I Basic Profile を規定しています。

J2EE1.4の特徴の１つとして、Webサービス関連のAPIが追加になったことがあげられます。

●Web Services for J2EE

●JAX-RPC

●SAAJ (Soap with Attachment API for Java)

●JAXR (Java API for XML Registry)

33


練習問題

⑧Webサービスの説明について正しい記述を２つ選びなさい。

A. JSP 2.0B. EJB 3.0C. JAX-RPCD. JavaServer Faces (JSF)

⑦J2EE1.4に含まれるAPIとして正しいものを２つ選びなさい。

A. Webサービスは、インターネットの標準技術を用いて、遠隔にあるソフトウェア・コ

ンポーネントの呼び出しを可能にする

B. Webサービスは標準化されていないので、異なるベンダーのアプリケーション・サ

ーバー間では接続できない

C. SOAPのトランスポート・プロトコルはHTTPに限定される

D. J2EE1.4では、XMLを用いたRPCとして、JAX-RPCを採用している

<memo>

34


5． WebSphere Application Server の管理

<memo>

35


WAS V6 システム構成

プロセス１

ノード・エージェント

ノードA

デプロイメント・マネージャー

プロセス２

EARファイル

セル構成情報

NodeA構成情報

プロセス1構成情報


プロセス３

ノード・エージェント

ノードB

プロセス４

EARファイル

セル構成情報

NodeB構成情報



Cell全体の構成情報のマスター

セル構成情報

NodeA構成情報



NodeB構成情報



APサーバー

APサーバー

APサーバー

APサーバー

EARファイル

デプロイメント・マネージャーは全てのノードおよびプロセス情報を持つ。ノード・エージェントは自分のノードの情報を持つ。デプロイメント・マネージャーとノード・エージェントは同期を取っているため、デプロイメント・マネージャーでの構成変更は全ての

ノードに反映される。

デプロイメントマネージャーに障害があっても各ノードは正常に稼動

セセルル

WAS-ND版

同期同期

管理コンソール管理ツール

XML構成ファイル

WAS V6 NDでのシステム構成は次のようになっています。

NDでは複数のアプリケーション・サーバーを一元管理することができます。この管理の単位をセルと呼

びます。セルには必ず一つのデプロイメント・マネージャーと呼ばれるプロセス(JVM)が存在し、セル全体

の構成情報を管理しています。管理者が管理コンソールや管理ツールを使ってWASにアクセスする時は、

このデプロイメント・マネージャーに接続することになります。デプロイメント・マネージャーはセルの静的

な構成情報を管理しているだけなので、デプロイメント・マネージャーに障害があったからといって、セル

内のアプリケーションが全面ダウンという訳ではありません。

各物理的なマシン（ノード）には、それぞれノード・エージェントと呼ばれるプロセス(JVM)が存在します。こ

のノード・エージェントは、デプロイメント・マネージャーと相互に通信し、同期を取りながら、自分のノード

配下にあるアプリケーション・サーバー・プロセス（JVM）の構成情報を管理します。また、ノード・エージェ

ントは、自分のノードのアプリケーション・サーバーを監視し、アプリケーション・サーバーがダウンした場

合に、再起動を試みます。

NDにおいては、セル内に複数のノードを構成することができます。また各ノード上には複数のアプリケー

ション・サーバーを構成することができます。

他方、ExpressとBaseはシングルサーバー構成のみのサポートとなっており、デプロイメント・マネージャ

ーやノード・エージェントといったプロセスは存在しません。

またWAS V6の新機能として、IBM HTTP Serverをセルの管理対象に含めることができるようになりまし

た。管理コンソールから、IHSの起動・停止や構成ファイル(httpd.conf)を編集することができます。

36


WAS V6 の導入・構成

WAS V6から新たにプロファイルという概念を追加

製品のシステムファイル（製品バイナリ）と、ユーザーの構成ファイル（プロファイル）を分離

プロファイルは１つのノード上のWAS JVMプロセスの実行環境を定義するファイルを

保持する

• 構成ファイル・データファイル・ログファイル等

プロファイルのタイプとして、Deployment Manager、Application Server, カスタム(DMが管理するノード)の3種類を提供

プロファイルの作成は、プロファイル作成ウィザードかwasprofileコマンドで

１つの製品バイナリの下に、複数のプロファイルを作成可能、

WAS V6 導入の手順

1. 製品をインストール

2. 導入後に適切なプロファイルを作成する

V6での新機能

WAS V6では、製品のシステムを構成するバイナリファイルと、サーバーごとの情報を構成するファイル

が分離されました。後者をプロファイルと呼びます。プロファイルの中には、ノードで稼動するWASプロセ

スの実行環境を定義する構成ファイルやデータファイルが含まれるほか、ログファイル等も入ります。

WAS V6でのインストール手順は大きく次の２つになります。

ステップ1：ウイザードを使用して製品をインストールします。（管理者権限でインストールすること）

ステップ2：製品をインストール後、プロファイル作成ウイザードが使用可能になります。このウィザードを

使用して構成する環境に合わせたプロファイルを作成します。

37


管理コンソールスクリプト - wsadmin

JMX コマンド／シェル

WAS V6 管理ツール

ブラウザーからアクセスhttp://<hostname>:9060/ibm/console

ND:デプロイメント・マネージャーBase＆Express：アプリケーション・サーバー

スクリプト・インターフェース言語としてJACL, Jythonをサポート

J2EE1.4で規定されているJMX (Java Management Extensions) の実装

サーバーの開始・停止等の操作をシェル／バッチコマンドとして提供

V5からURL変更

アプリケーションのインストールや開始・停止、サーバーやリソースの構成などの管理タスクは、以下の管理ツールを通して行います。

●管理コンソール

●スクリプトのwsadmin

●コマンド／シェル

●JMX

JMX（Java Management Extensions）とは、Javaからアプリケーション・サーバー等のシステム管理を行うためのAPIで、J2EE1.4で必須となっています。WASではV5の時からJMXを実装しています。WAS V6で提供される管理コンソールやスクリプト・インターフェース等の管理ツールを用いる場合も、内部的にはこのJMXのAPIが呼ばれています。また、WASが提供するこれらのツール以外に、JMX APIを用いてユーザー独自のシステム管理プログラムを作成することも可能です。

管理コンソールへはブラウザーからアクセスします。URLがV5から変更になりました。デフォルトでは、http://<hostname>:9060/ibm/console からアクセスします。

管理コンソールからはサーバーの構成・開始・停止やアプリケーションの導入、リソースの構成といったシステム管理全般を行うことができます。（ただしプロファイルの作成はできません）

スクリプト・インターフェースであるwsadminは、WAS V5から実装されていましたが、V6で機能が拡張されました。wsadminでも管理コンソールと同様の操作をコマンドラインから行うことができます。 wsadminではスクリプト言語としてJACLとJythonを正式サポートしています。

サーバーの開始・停止、起動状況の確認といった操作については、バッチコマンド(Windows環境)やシェル(UNIX環境)が用意されています。

以下は、使用頻度の高い、サーバーの開始・停止コマンドです。(コマンドの最後に windows環境では .bat が、UNIX環境では .sh が付きます)

startManager / stopManager ・・・デプロイメント・マネージャーの開始・停止

startNode / stopNode ・・・ノードエージェントの開始・停止

startServer / stoptServer <サーバー名> ・・・アプリケーション・サーバーの開始・停止

38


WAS V6 のワークロード管理

3段階でのWLM（ワークロード管理）を提供

Edge ComponentsによるWebサーバーへの負荷分散

WASクラスター構成によるWLM

① Edge ComponentsLoad BalancerによるHTTPサーバーへのWLM

② Webサーバー・プラグインによるWebコンテナーへのWLM

LBプライマリー

LBバックアップ

プラグイン

HTTPサーバー

プラグイン

HTTPサーバー

ｱﾌﾟﾘｹｰｼｮﾝ･ｻｰﾊﾞｰ

Webコンテナー


Webコンテナー


EJBコンテナー


EJBコンテナー

③EJBクライアントのWLMプラグインによるEJBコンテナーへのWLM

DB

WAS クラスター構成

WAS-ND版

WebSphere Application Server NDでは、3段階でのワークロード管理(Workload Management, WLM)を提

供しています

1．Edge ComponentsのLoad Balancerは、各Webサーバーの状況（コネクション数、CPU使用率やレスポ

ンスタイム等）からワークロードのバランスを考慮して、適切なサーバーへの振り分けを行ないます。Web

サーバーに障害が発生した場合は、別のWebサーバーに処理を割り振ります。

2．Webサーバーに導入されたプラグインが、プラグイン構成ファイル(plugin-cfg.xml)を参照して、Webコン

テナへの割り振りを行います。Webコンテナに障害があった場合は、別のWebコンテナに処理を割り振り

ます。以降、障害があったWebコンテナへの割り振りを停止しますが、plugin-cfg.xmlで定義されている

「再試行間隔」に達すると、再度リクエストの割り振りを試みます。また、Webコンテナへの割り振りはセッ

ション・アフィニティが優先されます。（セッション・アフィニティについては後述）

3．EJBコンテナへのリクエストは、EJBクライアントに含まれるWLMプラグインによって割り振りが行われ

ます。EJBのWLMでは、同一トランザクション内のリクエストについては前回と同じEJBコンテナへ割り振

られます。また「ローカルを優先」と指定することにより、EJBクライアントと同一ノード上にあるEJBコンテ

ナへ処理が割り振られるようになります。EJBのWLMの注意点としては、EJBクライアントとEJBコンテナ

が同じJVMプロセス上にある場合、リクエストは分散されず、必ず同じプロセス上のEJBコンテナに割り

振られるようになります。

39


WAS V6 の可用性 HA Manager

DM

NodeAgent

ApplicationServer

NodeAgent

NodeAgent

ApplicationServer

ApplicationServer

シングルトンサービスの引継ぎ

情報の共有・更新（WLM情報・障害情報等）

・構成情報の作成・変更・ JMX等の管理コマンド

・構成情報の同期・ AppServerへのPing・

再起動

Core Group

HAManager

HAManager

HAManager

HAManager

HAManager

HAManager

HAManager

障害検知

WAS-ND版

可用性を高めるための新機能

各JVMにHA Managerをビルトイン

シングルトン・サービスのHA機能を提供

V6での新機能

WAS V6では新たにHA Managerという機能が追加されました。HA Managerは、デプロイメント・マネージャ

ー、ノード・エージェント、アプリケーション・サーバーの各JVM上で稼動し、お互いにハートビートを出して

います。このHA Managerによって、セル内の情報の共有や障害検知、障害からのリカバリーが行われま

す。また、従来はデプロイメント・マネージャーのみが提供していた機能が複数JVMによって提供される

ようになったことにより、より高いレベルでのサービスが提供できるようになりました。

V6のHA Managerは、以下のシングルトン・サービスへのHA機能を提供します。

●EJBのWLMルーティング機能・・・V5ではデプロイメント・マネージャーがこの機能を提供していました

●メッセージング・エンジンのHA機能

●トランザクション・マネージャー・・・トランザクション・ログの引継ぎ

40


複数サーバー間でのセッション共有セッション・クラスタリング

HTTPプラグイン

Load　Balancer

HTTPサーバー１

HTTPプラグイン

HTTPサーバー２

HTTPプラグイン

HTTPサーバー３

AppServer

Webコンテナ２

AppServer

Webコンテナ１

AppServer

Webコンテナ３

①

②

③

④

HTTPプラグイン

HTTPサーバー

AppServer

Webコンテナ２

AppServer

Webコンテナ１

AppServer

Webコンテナ３

①

②④

③

④

セッション・アフィニティセッション・クラスタリング

セッション・オブジェクトを分散環境で共有

３つの方法

データベース

セッション・オブジェクトをDBに保存

Memory to Memory複製

セッション・オブジェクトを他のJVMへ保存

①Peer to Peer お互いのJVMで保存

②Client/Server 専用のJVMを用意して保存

同一クライアントからの要求は同一サーバーで処理• LoadBalancer → HTTPサーバー• HTTPサーバー間 → Webコンテナー

ただし、Webコンテナのダウンでセッションは失われる

WAS-ND版

セッション

セッション

セッション

セッション

ND環境でアプリケーション・サーバーのクラスタリングを行う場合のセッション管理について確認しましょう。

ショッピングカートなどの画面遷移を伴うアプリケーションではHttpSessionオブジェクトの仕組みが有効であることはご紹介しましたが、複数サーバーでクラスタリングが行われている場合、クライアントからの2回目のリクエストは必ず同じサーバーに割り振られる必要があります。別のサーバーに割り振られた場合は、サーバーのメモリー上に作成されたセッション・オブジェクトを参照できないため、再度ログイン画面が出てしまうことも考えられます。

同一クライアントからのリクエストを同じサーバーに割り振ることを、セッション・アフィニティと呼びます。WAS V6 NDでは、HTTPサーバーからWebコンテナへの割り振りにおいて、セッション・アフィニティが有効となります。

上図（左）の例では、クライアントからの最初のリクエストがWebコンテナ１に割り振られ、Webコンテナ１上にセッション・オブジェクトが作成されています。Webサーバーのプラグイン機能により、以降のリクエストについても必ず同じWebコンテナ１に割り振られる仕組みが提供されています。

しかし、Webコンテナに障害が発生した場合や、メンテナンスでサーバーを停止する場合には、そのコンテナ上で作成されたセッション・オブジェクトが利用できなくなってしまいます。そのため、セッション情報を全サーバーで共有するための仕組みが必要になります。セッション情報を全サーバーで共有することをセッション・クラスタリングと呼びます。これはセッション・オブジェクトを永続化するセッション・パーシスタンス機能によって実現されます。（セッション・パーシスタンスとはセッション情報を永続化することであって、必ずしも複数サーバー間で共有することを意味してはいません。）

WAS V6では、３つのセッション・クラスタリング方法を提供しています。ひとつはデータベースにセッション情報を書き込み、全サーバーで共有する方法です。もうひとつがメモリー上で共有する方法で、Memory to Memory複製と呼ばれています。メモリー間の複製には、アプリケーション・サーバー間で相互にレプリケーションするPeer to Peer方式と、セッション・オブジェクト保管専用のJVMを用意して共有するClient/Server方式の二通りあります。

上図（右）の例では、Webコンテナ１で作成されたセッション・オブジェクトをWebコンテナ２、および３に複製しています。Webコンテナ１がダウンした場合でも、セッション情報は失われず、クライアントは接続先のサーバーが変わったことを意識することなく処理を続行することができます。

※メモリー間で相互に複製するPeer to Peerの場合は、サーバー台数が多くなった場合に、JVMのメモリーを逼迫しますので注意が必要です。

41


新しいメッセージング・エンジン

WAS V6では新しいメッセージング・エンジンを搭載

Pure Java JMS1.1プロバイダー

• V5のEmbedded JMSサーバーは、Pure Javaではなかった

アプリケーション・サーバーJVM（プロセス）の一部として稼働する

• 各アプリケーション・サーバーがメッセージング・エンジンを持つ

• V5では、アプリケーション・サーバーとは別プロセスとして稼動

MQと同等の機能を提供し、相互接続も可能

外部のDBにメッセージを永続化できる

WAS NDにおいては、HA機能の対象であり、メッセージング・エンジンも

HAManagerによってフェイルオーバーされる

ESB (Enterprise Service Bus) のエンジンとして使用される

SIBus（サービス統合バス）を提供


次に、メッセージング関連の機能強化について紹介します。

WAS V6では、新しいJavaベースのメッセージング・エンジンが搭載されました。新しいメッセージング・エ

ンジンは、アプリケーション・サーバーJVMの一部として稼働するようになりました。すなわち、それぞれ

のアプリケーション・サーバーが自分用のメッセージング・エンジンを持つようになります。機能的には、

WebSphere MQと同等の機能を提供し、WebSphere MQとの相互接続も可能になりました。メッセージの

信頼性を5段階で指定することができ、データベースにメッセージを保管し、障害時にも復旧の対象とな

るパーシスタンス・メッセージも選択できます。パーシスタンスとして、内蔵のCloudscapeデータベースや、

外部のDB2やOracleにメッセージを保管することができます。ただし、信頼性を高めると、処理のパフォー

マンスは落ちますので、ご注意ください。

新しいメッセージング・エンジンはHA機能の対象であり、障害時もフェイルオーバーされます。

このメッセージング・エンジンは、ESBのエンジン（WASではSIBusと呼ぶ）として重要な役割を果たしてい

ます。

42


WAS V6 のセキュリティ

WAS V6 がサポートするセキュリティ

Java2セキュリティ・モデル、SSL通信、JAAS (Java Authentication and Authorization Service)、CSIv2セキュリティ・プロトコル、SAS認証プロトコル、etc

グローバル・セキュリティ

管理コンソールや管理ツールのログインにパスワードが必要となる

ユーザー・レジストリの構成が必要

管理コンソールを使用するユーザーに対して４つのロールを定義

• 管理者、コンフィギュレーター、オペレーター、モニター

• ロールによって機能が制限される

鍵管理ユーティリティ IKEYMANの提供

SSL構成で必要となる鍵ファイル、トラストファイルを作成できる

シングルサインオン(SSO)のサポート

WAS V6では、SSL通信、JAAS、CSIv2セキュリティ・プロトコルなど様々なセキュリティ機能を提供してい

ます。

グローバル・セキュリティはセル全体に有効になります。管理コンソールやwsadminへのアクセスに制限

をかけることができます。グローバル・セキュリティを使用可能にするには、ユーザー・レジストリや認証メ

カニズムを構成する必要があります。グローバル・セキュリティを使用可能にした後は、ユーザーIDとパ

スワードで認証されます。また、管理者、コンフィギュレーター、オペレーター、モニターといった４つの役

割が定義されており、各役割によって使用できる機能が制限されます。

SSL構成で必要となる鍵ファイル、トラストファイルを作成するためのGUIのツールIKEYMANを提供してい

ます。

WAS V6では、トラストアソシエーションやシングルサインオンの機能も提供しています。

43


パフォーマンス関連機能

パフォーマンス向上のための機能

DynaCache (動的キャッシュ)• ServletやJSPの出力をキャッシュする機能

• ND環境では、クラスター・メンバー間でキャッシュを複製可能

• Edge Componentsのキャッシング・プロキシやIHSにキャッシュを配置可能

• キャッシュの利用方法や、キャッシュのクリア方法を提供

パフォーマンス・モニタリング機能

PMI (Performance Monitoring Infrastructure)

• アプリケーションサーバーに関する様々なシステム測定値をユーザーが取得するための標準API

Tivoli Performance Viewer

• 管理コンソールに統合

パフォーマンス・アドバイザー

要求メトリック


WAS V6が提供するパフォーマンス関連の機能をご紹介します。

パフォーマンスを向上する仕組みの１つとして、以前のバージョンからDynaCache（動的キャッシュ）が提

供されています。これは、ServletやJSPの出力結果をアプリケーション・サーバー上に保持し、同じリクエ

ストが来た場合にはキャッシュから返す仕組みです。アプリケーション・サーバー上ではなく、その前面の

IBM HTTP Serverや、Edge Componentsが提供するキャッシング・プロキシー上にキャッシュを保持する

ことも可能です。このことにより、レスポンスタイムの向上や、サーバーにかかる負荷の軽減が期待でき

ます。またND環境においては、クラスター・メンバー間でキャッシュを複製することもできます。どういった

場合にキャッシュから利用するかという設定や、キャッシュのクリア方法についても細かい制御が可能と

なっています。

パフォーマンス状況をモニターする仕組みも提供されています。

PMI (Performance Monitoring Infrastructure)とは、様々なシステム測定値をユーザーが取得するための

標準APIです。取得する対象のコンポーネントやレベルについてはユーザーが選択することができます。

Tivoli Performance Viewerは、PMIで取得された情報を表示するためのビューワーです。V5では専用の

Javaアプリケーションで、個別に起動する必要がありましたが、V6では管理コンソールに統合されました。

パフォーマンス・アドバイザーは、取得したパフォーマンス・データに基づき、リソース構成についてのアド

バイスを提示する機能です。管理コンソール上に推奨設定を表示します。

要求メトリックは、Webサーバー、Webコンテナ、EJBコンテナといった各コンポーネントでの処理時間を記

録し、ARM形式でデータを提供します。リクエストから結果が返るまでの一連の流れの中でボトルネック

を判断するために有効なツールです。

44


練習問題

⑨WAS V6がサポートする管理ツールを２つ選びなさい。

⑩WAS V6 NDの分散トポロジーにおいて、セルに１つだけ存在し、セルの構

成情報を一元管理するためのプロセスを１つ選びなさい。

A. 管理コンソール

B. wsadminC. XML ConfigD. wscp

A. アプリケーション・サーバー

B. ノード・エージェント

C. JMSサーバー

D. デプロイメント・マネージャー

<memo>

45


練習問題

⑪WAS V6が提供するHA Managerについて正しい記述を２つ選びなさい。

⑫WAS V6が提供するメッセージング・エンジンについて正しい記述を２つ選びなさい。

A. デプロイメント・マネージャー、ノード・エージェント、アプリケーション・サーバー

の各プロセス上で稼動する

B. セルの構成情報やインストールされているアプリケーションを管理する

C. EJBのWLMルーティング機能を提供する

D. デプロイメント・マネージャーのHA機能を提供する

A. Pure Javaで書かれたJMSプロバイダーである

B. メッセージはメモリー上に保管され、サーバーの再起動で全て失われる

C. HA機能の対象で、障害時にフェイルオーバーされる

D. WebSphere MQとの相互接続性はない

<memo>

46


6．アプリケーションの管理

<memo>

47


J2EEアプリケーションの導入

アプリケーションが稼動するために必要な作業

リソースの定義

アプリケーションのデプロイ

アプリケーション・サーバーデータベース

メッセージング

JDBCプロバイダー

JMSプロバイダー

アプリケーション（ear）

アプリケーション（ear）

デプロイ

アプリケーション・サーバーデータベース

メッセージング

JDBCプロバイダー

JMSプロバイダー

J2EEアプリケーションをサーバーに導入して稼動させるために必要な作業には、リソース定義とアプリケーションのデプロイがあります。

リソース定義とは、アプリケーションがデータベースやメッセージングといったリソースに接続するために、サーバー側で必要な情報を設定しておくことです。

アプリケーションのデプロイとは、開発したアプリケーションをサーバーにインストールしたり、サーバーに既にインストールされているアプリケーションを更新したりすることです。

リソース定義は管理コンソールやwsadminから行います。データベースにアクセスするには、JDBCプロバイダやデータソースの定義が必要になります。また、メッセージングを行うためにはJMSプロバイダの定義が必要です。これらリソースには、有効になるスコープが関連付けられます。WAS V6 NDでは５つのスコープが利用できます。スコープの範囲が広い順に、セル、クラスター、ノード、サーバー、アプリケーションとなりますが、管理コンソールやwsadminから定義できるスコープはセルからサーバーまでとなります。アプリケーションというスコープは次ページで紹介するEnhanced EARにて使用されます。また、リソースはスコープが小さい方から優先されます。

アプリケーションのデプロイ（インストール）は、管理コンソールやwsadminといった管理ツールから行います。WAS V6ではEARファイルまたはWARファイルの単位でインストールできます。たとえば管理コンソールでは、「アプリケーション」→「新規アプリケーションのインストール」を選択し、ステップに沿って順に設定していくと容易にインストールすることができます。ステップの最後には要約画面が出てきますので、内容を確認し、問題がなければ保管して構成情報を反映させます。導入したアプリケーションは、デフォルトでは、各プロファイル下のinstalledAppsディレクトリに展開されます。

また、クラスターに対してアプリケーションをデプロイした場合には、各クラスター・メンバーに定義が反映され、EARファイルは自動で全クラスター・メンバーに配布されます。

インストールの対象としてWARファイルを指定する場合には、アプリケーションのDeployment Descriptor (enterprise.xml)で指定されるコンテキストルートを、インストール時に指定する必要があります。

48


Enhanced EAR

Enhanced EARはサーバー構成情報を含んだEAR

データ･ソース

クラス・ローダー・ポリシー

置換変数

ＪＡＡＳ認証

共用ライブラリー

仮想ホスト

デプロイの簡略化を実現

デプロイ時の設定項目数を減少

複数サーバーへのデプロイ時にも設定は1度

J2EE App.EAR

Properties

Resources

Enhanced EAR

V6での新機能

Enhanced EAR とは、アプリケーションが稼動するためにサーバー側で必要となる情報をアプリケーショ

ンと一緒にアーカイブしたファイルのことです。アプリケーションと一緒にアーカイブされるのは、リソース

定義情報やプロパティー設定情報などです。IBM Rational Application Developerなどの開発ツールから

Enhanced EAR をエクスポートしてサーバーにデプロイすれば、サーバー側でアプリケーションの稼動に

必要なリソース定義などを行う必要がなくなります。

49


アプリケーションの更新 Fine-Grained Update

Fine-Grained Update とは

アプリケーションを部分的に追加 / 更新 / 削除する機能

管理コンソールや管理スクリプトを使用した実行が可能

更新単位

アプリケーション、モジュール、ファイル、アプリケーションの一部

更新 / 反映

サーバー稼動中に更新した場合、アプリケーション全体あるいは更新の影響を受ける

一部だけを自動停止、更新、再起動

Application.ear

WebModule.war

FileA

EJBModule.jar

FileB

管理コンソール更新

更新

更新

V6での新機能

Fine-Grained Update とは、アプリケーションを部分的に追加、更新、削除できる機能です。これらの操作

は、管理コンソールや wsadmin といったWASが提供している管理ツールを使用して実行することができ

ます。V5でアプリケーションを部分的に更新するためには、アプリケーションが展開されているディレクト

リのファイルを直接置き換えるなどといった手動による方法しかありませんでした。V6では、管理ツール

から Fine-Grained Update を実行すれば、アプリケーションの部分的な更新を展開ディレクトリに自動で

反映させることができます。

アプリケーションを更新できる単位としては、アプリケーション、モジュール、ファイル、アプリケーションの

一部という4種類がサポートされています。

この機能を使用した場合、アプリケーション・サーバーを停止することなくアプリケーションを更新すること

ができます。更新する際、更新内容に応じて、アプリケーション全体あるいは更新の影響を受ける一部だ

けが自動で停止され、更新されたのち再起動されます。

50


アプリケーションの更新 Rollout Update

Rollout Update とは

クラスター上のアプリケーションへの更新を

一斉におこなうのではなく、自動でノード毎に順番

に反映する機能

以下の作業をノードごとに自動的に行う

ノードのアプリケーションサーバーの停止

ノード上のアプリケーションの更新

アプリケーションサーバーの始動

サーバークラスター

Application

クラスターメンバー3

Application


Application

Rollout Update実行

① 反映

② 反映完了

③ 反映

④ 反映完了

⑤ 反映

⑥ 反映完了


Application


Application

管理コンソール

WAS-ND版

V6での新機能

Rollout Update とは、クラスター上のアプリケーションを更新する際、クラスターに対する更新を全てのク

ラスター・メンバーに同時に反映させるのではなく、ノード毎に順番に反映させていくという機能です。こ

の機能を使用すると、クラスターを構成している複数ノードのうち常にいずれかのノード上のクラスター・

メンバーは稼動しているため、サービス全体としては停止することなくアプリケーションの更新を行うこと

ができます。

51


J2EE1.4への拡張 JSFとSDO

Webアプリケーションにおけるユーザー・インターフェース構築のためのフレーム

ワーク Servlet、JSP上で構築される MVCモデル2に準拠 JCPによる標準化（JSR127）、J2EE1.5に含まれる予定

開発ツールによるサポートで、ユーザー・インターフェースの開発生産性を高める WebSphereでは、JSFで必要となるJarファイルを提供

JavaServer Faces (JSF) とは

Service Data Objects (SDO) とは

様々なデータに対する統一的なプログラミングモデルを提供非同期型データアクセスをサポート WebSphereでは、RDBにアクセスするための、JDBC Data Mediator

Serviceをサポート IBMとBEA SystemによってJSR235としてJCPに提唱


J2EE1.4には含まれていませんが、JCPによって標準化が進められている２つの仕様、JSFとSDOについ

て簡単に紹介します。

JavaServer Faces (JSF)は、Webアプリケーションにおけるユーザー・インターフェース構築のためのフレ

ームワークで、ServletとJSP上で構築されます。現在、Webアプリケーションのフレームワークとしては、

JakartaプロジェクトのStrutsが有名ですが、JSFもStrutsもMVCモデル2に準拠しています。また、Struts

はデファクトスタンダードではありますが、JCPによって規定されている仕様ではありません。一方JSFは、

JCPでJSR127として標準化が進められており、J2EE1.5に含まれる予定になっています。既に多くの開発

ツールがJSFをサポートしており、Webアプリケーションにおけるユーザー・インターフェースの開発生産

性向上が期待されています。WebSphere Application Server V6では、JSFで必要となるJarファイルを提

供しています。(V5の時にはEARファイルに含める必要がありました。)

Service Data Objects (SDO)は、多様なデータに対して統一されたデータアクセスを提供します。アーキ

テクチャーとしては、アプリケーションからアクセスするためのSDO Core APIと、それぞれのデータにアク

セスするためのData Mediatorサービスから成ります。WebSphere Application Server V6では、RDBにア

クセスするためのJDBC Data Mediator Serviceをサポートしています。

52


J2EE1.4への拡張 WebSphere Extensions

WebSphereが提供するJ2EEへの拡張機能

J2EE1.4には含まれていないWebSphere独自の機能

Express、Base、NDで同じ機能を提供

WAS V5では、Enterprise版でのみ使用可能であったPME（Programming Model Extensions）を、Express版から使用できるように変更

以下の機能を提供

プログラミング・モデルの拡張

最先端の機能の提供

プログラミングやデプロイメントの効率化

ワークフロー機能(Service Choreography)については、引き続きWBI-SFでのみ

サポート


WebSphere Extensionsは、V5ではPME (Programming Model Extensions)と呼ばれていたものの一部です。PMEは、WebSphere Application Server Enterprise (V5)、あるいはWebSphere Business Integration Server Foundation (V5.1)に含まれていましたが、V6ではWASの標準機能として取り込まれています。このことによって、拡張機能に対しても、WASのエディションを問わず利用できるようになりました。

WebSphere Extensionsは、 J2EE1.4 へのWebSphereの機能拡張の総称です。このうちのいくつかはJSRにて仕様が決められており、将来のJ2EE仕様に含まれると考えられます。

V6では以下の機能を提供しています。

Timer for Application Servers、

Work Manager for Application Servers

非同期（マルチスレッド）プログラミングのための仕組み

Startup beans

アプリケーション (EAR) の起動と終了時に、自動的に呼び出されるStateful Session Bean

Object pools

オブジェクトをプールして再利用するための仕組み

Work Area

アプリケーション・コンポーネント間で情報を伝達するための仕組み

Dynamic Query

EJB QLの機能の拡張版

Activity Session

JTAトランザクション・サービスの拡張

Last Participant

複数のリソースの同時更新において、1フェーズ・コミット(1PC)のみをサポートするリソースが一つのみ存在する場合に使用可能

Dynamic Cache

Servlet/JSP、コマンド、Webサービスの結果をキャッシュする仕組み

53


練習問題

⑬WAS V6でのアプリケーションのデプロイについて正しい記述を２つ選びなさい。

A. アプリケーションを更新する場合は、必ず先にアプリケーションを手動でアンイ

ンストールしておく

B. 管理コンソールやwsadminからデプロイすることができる

C. デプロイ前にアプリケーションで必要なリソースを作成しておく

D. クラスターにアプリケーションをデプロイする場合は、クラスター・メンバー毎に

デプロイ作業を実行し、EARファイルを各ノードに手動でコピーする

<memo>

54


練習問題回答

① A,D② A,C③ C④ D⑤ B,D⑥ D⑦ A,C⑧ A,D⑨ A,B⑩ D⑪ A,C⑫ A,C⑬ B,C

お疲れ様でした。WebSphere アドバイザー試験がんばってください。

<memo>

websphere application server v6 アドバイザー 認...

Documents

websphere application server v6 アドバイザー認...