WebSphere Application Server 概説 1 WebSphere Application Server V6.0 - シングルサーバー編 -
by user
Comments
Transcript
WebSphere Application Server 概説 1 WebSphere Application Server V6.0 - シングルサーバー編 -
WebSphere Application Server 概説
WebSphere Application Server V6.0
- シングルサーバー編 -
WebSphere Application Server 概説
1
WebSphere Application Server 概説
Agenda
WebSphere Application Server 登場の背景
プログラミングモデル
構成の基本
アプリケーションの実行
まとめ
当資料では以下の略語を使用しています。
( )内が正式名称になります。
製品名
WAS
(WebSphere Application Server)
ND
(WebSphere Application Server Network Deployment)
RAD
(IBM Rational Application Developer for WebSphere Software)
RWD
(IBM Rational Web Developer for WebSphere Software)
製品に含まれるコンポーネント
IHS
(IBM HTTP Server)
2
WebSphere Application Server 概説
WebSphere Application Server 登場の背景
3
WebSphere Application Server 概説
次世代のオンデマンド・ビジネスを支える技術
機
能
の
拡
張
WebService
エンタープライズ・システムとの統合
動的なアプリケーション結合
XML
ビジネスでの利用の本格化
Servlet
EJB
データ交換言語の標準化
JSP
BtoCビジネスへの利用
サーバーサイドJavaによる動的コンテンツ
J2EEとして標準化
CGI
情報発信
（一方的）
HTML
既存言語による動的コンテンツ
Applet
クライアントサイドJavaによる
動的コンテンツ
静的コンテンツ
時代の流れ
近年急速に普及したインターネット、中でもWorld-Wide-Webに代表される
Webテクノロジーは、当初は固定のテキストと画像による一方的情報発信の手
段でしたが、ユーザーの要求に応じてサーバー側でプログラムを実行させ、複
雑な処理を行うことが可能となったことにより、広くビジネスにも使われるように
なってきました。
初期のサーバー側プログラムはCGIと呼ばれ、既存の言語（PerlやCなど）で書
かれていましたが、Java言語の広まりと標準化の進展（J2EEの発表）につれて、
サーブレット（Servlet）・JSP・EJBなどJavaの技術を利用したものが主流となっ
てきています。
さらに最近では、XML言語によるデータ交換の標準化や、コンピューターによっ
て利用可能なサービスをWeb上で動的に結合する技術（Webサービス）の登場
で、オンデマンド・ビジネスはますますダイナミックなものとなっています。
4
WebSphere Application Server 概説
WebSphere Application Server の基本構成要素
アプリケーションサーバー
アプリケーションを稼動させるうえで必要となる共通の機能を
提供するミドルウエア
J2EEアプリケーション実行環境（以下の機能）を提供
HTTPトランスポート
Embedded HTTP Serverとも呼ばれる
アプリケーション・サーバーごとに存在
Application Server
Webコンテナー
サーブレット,JSPなどの
Webアプリケーションの実行環境
EJBコンテナー
EJBの実行環境
ネーミングサービス
クライアント
名前をもとにオブジェクトを
検索するためのサービス
JMSプロバイダー
JMSインターフェイスを備えた
メッセージングシステムをJ2EE上での実装
Web
サーバー
Webサーバー
プラグイン
ネーミングサービス
Web
コンテナー
HTTPトラン
スポート
EJB
コンテナー
JMS
プロバイダー
Webサーバー上の構成要素
Webサーバー
HTTPリクエストを受け付ける
Webサーバー・プラグイン
Webサーバーのプロセス内で稼働し、アプリケーション・サーバーへの要求をフォワード
○アプリケーションサーバー
アプリケーションを稼動させるうえで必要となる共通の機能を提供するミドルウェアです。
J2EE1.4準拠のアプリケーションサーバーで、一つのJavaプロセスとして稼動します。以下の機能を提供
します。
○HTTPトランスポート
Webサーバープラグインから送られてくるHTTP通信の受け口です。プラグインとの問題切り分け
のために直接アクセスすることもあります。
○Webコンテナー
サーブレットやJSPの実行環境を提供します。サーブレット・インスタンスの作成、サーブレットの
ロードとアンロード、Requestオブジェクト・インスタンスとResponseオブジェクト・インスタンスの
作成と管理ならびにサーブレットを効率的に管理するためのタスクを実行します。
○EJBコンテナー
EJBの実行環境を提供します。EJBコンポーネントのトランザクション管理を提供します。EJBコン
テナが提供する機能を使用することにより、ユーザープログラムにおけるシステム関連のコードの
開発量を削減し、シンプルなコンポーネントとしてのBeanが作成できます。
○ネーミングサービス
オブジェクト（データソース、EJBホーム・インターフェースなど）と名前とを関連づけ、その名前を
キーとしてオブジェクトを検索するためのサービスです。
○JMSプロバイダー
JMSとはJava Messageing Serviceの略で、J2EE標準のメッセージングインターフェースです。
JMSプロバイダーはJ2EEサーバー上でJMSの実行環境を提供します。
○Webサーバー
HTTPのリクエストを受け付けます。
○Webサーバー・プラグイン
受け付けたリクエストを見てサーブレットやJSPへのリクエストであると判断すると、WASへリクエストを転送
します。
5
WebSphere Application Server 概説
WebSphere Application Server 製品構成
WAS
WAS Network
Network Deployment
Deployment (ND)
(ND)
分散環境で、
最新のクラスタリング、
HA(高可用性)機能、
管理機能を提供
WAS
WAS
シングルサーバーの
実行環境を提供
WAS-Express
WAS-Express
ISVソリューションの基盤
®
Linux
Linux
®
AIX
AIX
®
Solaris
Solaris
その他のファミリー
WebSphere Extended Deployment
(XD) V6.0
動的な拡張性、高パフォーマンス
HP-UX
HP-UX
スケールアップ /メインフレーム・コンピューティング
Windows
Windows
®
®
OS/400
OS/400
®
z/OS
z/OS
WebSphere
Application
Server
for z/OS
WebSphere
Application Server
Network
WebSphere
Application Deployment
Server
WebSphere
Application
Server
Express
WebSphere
Extended
Deployment
スケールアウト/分散コンピューティング
WebSphere Application Server Express版は、最もエントリーレベルに位置し、パッ
ケージ製品のベースとして使用されることが期待される製品です。
その上位はWebSphere Application ServerのBase版になります。シングルサーバー
環境のみのサポートとなりますので、限定された規模のシステムでの使用となります。さ
らに上位のWebSphere Application Server Network Deployment版は、クラスタリング
機能や、負荷分散機能を提供していますので、通常想定されるWebシステム全般にわ
たり使用が可能です。
また、WebSphere Application Server のその他ファミリーとして、大規模なシステム向
けの製品としてWebSphere Extended Deployment (XD)があります。動的な拡張性や
高いパフォーマンスを実現しています。
6
WebSphere Application Server 概説
WebSphere Application Server V6 パッケージング
内容
WAS – Express
WAS
WAS ND
導入可能CPU数
２CPUまで
無制限
無制限
J2EE 1.4サポート
○
○
○
IBM HTTP Serverと
Web Server plug-inの同梱
○
○
○
64 bit対応
×
○
○
Edgeコンポーネント
×
×
○
クラスター構成
×
×
○
同梱開発ツール
RWD*
RAD** 試用版 RAD** 試用版
* : Rational Web Developer for WebSphere Software (WSSDの後継製品）
** : Rational Application Developer for WebSphere Software (WSADの後継製品)
WAS Express、Base、Network Deploymentの各製品に含まれる機能と同梱される
パッケージをまとめると上記のようになります。
製品すべてJ2EE1.4の完全サポートで、またWebサーバーとして、「IBM HTTP
Server(IHS)」が同梱されます。複数サーバーを用いたクラスター環境の構築には
Network Deployment が必要になります。Express版の制限としては、2CPUマシンま
でという点と64bit対応でないという点があります。また開発ツールはRational Web
Developer for WebSphere Software を使用します。Network Deployment版には、ソ
フトウェアによる負荷分散機能を含むEdgeコンポーネントが含まれます。
7
WebSphere Application Server 概説
サポートOS
最新の情報は下記Webサイト参照
http://www-306.ibm.com/software/webservers/appserv/doc/latest/prereq.html
オペレーティングシステム
Windows
AIX
Sun Solaris
HP-UX
Linux/Intel
Linux/PPC
zLinux (Express版除く)
I5/OS and OS/400
z/OS (Express版を除く)
HP−UX 64bit (Express版を除く)
Linux 64bit (Express版を除く)
バージョン
Windows 2000 Advanced Server, Server, Professional
Windows Server 2003 Datacenter, Enterprise, Standard
Windows XP Professional
AIX 5.1、AIX 5.2、AIX 5.3
Solaris 8、Solaris 9
HP-UX 11 lv1
Red Hat Linux Enterprise 3.0
United Linux 1.0
SuSE Linux Enterprise Server 8, 9
OS/400 5.2, 5.3
z/OS 1.4, 1.5, 1.6
z/OS.e 1.4, 1.5, 1.6
HP-UX 11 lv2 Update2
(AMD/intel)
Red Hat Enterprise Linux AS 3.0 Update 3 or 4
Red Hat Enterprise Linux ES 3.0 Update 3 or 4
SUSE Linux Enterprise Server 9
(iSeries,pSeries)
Red Hat Enterprise Linux AS 3.0 Update 3 or 4
SUSE Linux Enterprise Server 9 SP1
WebSphere Application ServerはWindowsから各種Unix系OS、Linux、iSeries、
zSeriesまで、様々なプラットフォームで稼動します。最新の情報は、Webサイトで確認
してください。
Expressは、zLinux、z/OS、HP-UX 64bit、Linux 64bitはサポートしません。
8
WebSphere Application Server 概説
WebSphere Application Server トポロジー概要
アプリケーション・サーバー
一つのJVM上で稼動するJavaプロセス
Web/EJBコンテナー、ネーミングサービス、リソース管理などが含まれる
ノード
通常は物理的な一つのマシンに対応する
一つのマシン上に複数のノードを構成することも可能
アプリケーション・サーバーの集まり
シングルサーバー構成
ノード
セル
サーバーA
ノードの集まり。論理的な管理の単位
デプロイメントマネージャーはセルを構成するすべてのノードを
セル
ノード・エージェント経由で管理
マルチサーバー構成
デプロイメントマネージャー
ノードエージェント
サーバーA
サーバーB
ノードエージェント
サーバーC
サーバーD
Express/Baseは、シングル・サーバー構成のアプリケーション･サーバー環境です。シングル･サーバー
環境とは、単一のJVM上でアプリケーション、管理操作、統合JMSプロバイダー等を実行するものです。
ノード・エージェント、デプロイメント･マネージャは、Network Deployment のコンポーネントで、Express、
Baseにはありません。また、Express/Baseでは、単一プロセスによるスタンドアローン構成であり、ブラウ
ザからの起動、停止、動作状態の把握、再起動などの上位の監視プロセスを必要とする機能は提供され
ません。
○アプリケーションサーバー
アプリケーションの実行環境を提供します。Webアプリケーションが稼動する最小の単位です。
○ノードエージェント
ノード全体を管理するプロセスでファイル転送サービスや構成情報の同期を行います。デプロイメントマ
ネージャーと通信してデプロイメントマネージャーの構成情報をノードの構成リポジトリーに反映します。
○ノード
アプリケーションサーバーを１つまたは複数まとめたもの、通常は１つの物理マシンに対応します。
○セル
セルとはノードの集合で論理的な管理の単位を指します。セル内の情報はマスター構成リポジトリーに集
中管理されます。
○デプロイメント・マネージャー
セル内に含まれるノードを集中管理する管理プロセスで、構成情報をマスター構成リポジトリーと呼ばれる
XML形式のファイルに保管します。
9
WebSphere Application Server 概説
プログラミングモデル
10
WebSphere Application Server 概説
J2EE
J2EE(Java 2 Platform Enterprise Edition)とは
Sunが作成したJavaによるサーバーサイドのエンタープライズ・シス
テム構築のためのアーキテクチャー
アプリケーション・サーバー・ベンダーが提供する機能と、その機能へのJavaプロ
グラムからのアクセス方法を明確に定義
その機能とは、企業向けのWebアプリケーション構築において、一般的に必要に
なるセッション管理、トランザクション管理、データベース接続、セキュリティ等
アプリケーション・サーバーの事実上の業界標準仕様
J2EEのメリット
ポータブルなアプリケーションの実行環境を提供
アプリケーションの開発を迅速かつ容易にできる
J2EEとは、Java 2 Platform,Enterprise Editionの略で、Sun Microsystemsが作成し
たJavaによるサーバーサイドのエンタープライズ・システムの構築のためのアーキテク
チャーです。Javaの基本機能を備えたプラットフォームであるJ2SE(Java 2
Platform,Standard Edition)をベースにして、エンタープライズ向けの各種APIや仕様
などを取りまとめたものです。つまり、アプリケーション・サーバー・ベンダーが提供する
機能と、その機能へのJavaプログラムからのアクセス方法を明確に定義したものです。
その機能とは、企業向けのWebアプリケーション構築において、一般的に必要になる
セッション管理、トランザクション管理、データベース接続、セキュリティーなどの機能も
含まれています。現在J2EEは、アプリケーション・サーバーの事実上の業界標準仕様と
なっています。
J2EEの利点は主に２つあります。
１つはポータブルなアプリケーションの実行環境を提供することです。ポータブルなアプ
リケーションとは、どのJ2EE準拠のアプリケーションサーバーでも稼動可能で、ベン
ダーやプラットホームに依存しない可搬性のあるアプリケーションのことです。
もう１つはアプリケーションの開発を迅速かつ容易にできるようにすることです。コンポー
ネントを再利用したり、豊富に提供されているフレームワークを利用してプログラミングを
行うことができます。フレームワークとはWebアプリケーションを構築するにあたって必要
となる共通の機能を提供するコンポーネントの集まりです。
11
WebSphere Application Server 概説
J2EEとWASの対応遷移
J2EE v1.2
1999年12月発表
J2EE v1.2.1
2000年5月 Final リリース
メンテナンス・リリース
J2EE v1.3
WebSphere Application Server V4
WebSphere Application Server V5
2001年 7月 Final リリース
J2EE v1.4
2003年11月 Final リリース
WebSphere Application Server V6
J2EE v5.0
(J2EE1.5から改称)
現在策定中 2005年後半予定
J2EEは1999年12月に発表され、以後少しずつ機能拡張、新しい規格の採用を繰り返
して発展してきました。WebSphereの新しいバージョンであるWebSphere AS V6は現
在の最新J2EEである、J2EE1.4に対応しています。また、J2EEの次のバージョンであ
るJ2EE5も見え始めていて、現在規約を策定中です。
J2EE5.0でJ2EE/J2SEのリリース番号が改称されているのは、リリース間隔を18カ月程
度に短縮し，新技術を取り入れやすいようにするためのものです。
12
WebSphere Application Server 概説
J2EEコンテナー･モデル
クライアント部分
WebSphere Application Server 部分
EIS部分
IIOP
IIOP
J2EEプログラミング・モデルには4つのタイプのアプリケーション・コンポーネント
があり、これらはアプリケーション・サーバー内の以下の4つのタイプのコンテ
ナーで稼動します。
EJBコンテナー
−Enterprise JavaBeans
Webコンテナー
−サーブレットおよびJavaServer Pagesファイル
アプリケーション・クライアント・コンテナー
−アプリケーション・クライアント
アプレット・コンテナー
−アプレット
J2EEコンテナーはアプリケーション・コンポーネントのランタイム・サポートを提
供します。J2EEアプリケーションではアプリケーション・コンポーネントのタイプご
とにコンテナーが１つ必要です。アプリケーション・コンポーネントとサービスの
セットとの間にコンテナーを持つことで、J2EEはアプリケーション・コンポーネント
用APIを統合して提供できます。
コンテナーはサービスへのアクセスで使用されるアプリケーション・コンポーネン
トにAPIを提供します。さらに、セキュリティ、リソース・プール、状態管理、および
ネーミングサービスやトランザクションを処理することもあります。
13
WebSphere Application Server 概説
（参考）MVCモデル
MVCモデル
J2EEで推奨されているデザインパターンのひとつ
アプリケーションをModel（ロジック）、View（プレゼンテーション）、
Controller（通信、制御）の部分に分割してそれぞれを独立して開発
していく
リクエスト
Controller
（サーブレット）
Model
（EJB）
（JavaBeans）
データベース
Webブラウザ
応答
View
（JSP）
MVCモデルでは、Webシステムにおいて必要になる処理をModel、View、Controllerに分け、それぞれ
の役割を担当するコンポーネントと結び付けています。
Controllerはクライアントからのページ要求の受付から、クライアントにページを返すまでの全体の制御を
行います。Controllerの役割としては、クライアントがブラウザーで入力した値を受付、適切なビジネスロ
ジックを実行するEJBやJavaBeansに処理を依頼します。最後に、クライアントへの返答ページの作成を
JSPに依頼します。このControllerの役割を担当するのが、サーブレットです。
Modelはデータベースなどのバックエンドシステムにアクセスして、データの取得・保管を行ったり、値の
計算などの純粋なビジネスロジックの実行を行います。EJBやJavaBeansがこの役割を担当します。
Viewはクライアントへ返答するWebページの作成を行います。JSPがこの役割を担当します。
このモデルに従うことで、役割ごとの分離が明確になりますので、開発者の分業がしやすくなり、ビジネス
ロジックの実装を担当する開発者と画面表示部分を担当する開発者などがそれぞれ得意とする分野の実
装に集中することができます。また、コンポーネント間の依存性が最小限に抑えられ、他の部分の変更に
よる影響を受けにくく実装することが可能になり、コンポーネントの再利用性が高まります。
注）MVCモデルはJ2EE BluePrintsが推奨しているデザインパターンのひとつです。
MVCをサポートするフレームワークとしてStrutsが存在し、Strutsをベースにしたアプリケーションをサポー
トする開発ツールとしてRWD、RADがあります。
14
WebSphere Application Server 概説
サーブレット概要
サーブレットとは
クライアントと対話型処理を行う、サーバー・プログラム
サーブレットの役割
クライアントから送付されたデータの取得
クライアントから送付されたデータのチェック・整形
整形したデータをJavaBeansやEJBに送付
JavaBeansやEJBからのデータをもとにHTMLページ作成をJSPに依頼
セッション情報の利用・制御
Controller
Webブラウザー
EJB または
JavaBeans
EJB または
JavaBeans
http://www.・・・
http://www.・・・
<
<HHT
TMML
L>><
<HHE
EAAD
D>>・
・・ ・・
・
Servlet
データベース
JSP
サーブレットは、クライアント（Webブラウザー）からの要求を処理し、結果をクライアントに返すサーバー・
プログラムです。具体的には、以下のような仕事を行います。
①クライアントから送付されたデータの取得
サーブレットを利用することにより、簡単にクライアントの入力データを取得することができます。
②クライアントから送付されたデータのチェック・整形
クライアントの入力したデータが正しいかをチェックし、また、データを整形します。
③整形したデータをビジネスロジックを実行するJavaBeansやEJBに送付
④JavaBeansやEJBから戻ってきたデータをもとにHTMLページ作成をJSPに依頼
戻ってきたデータに応じて、そのときそのときで異なるHTMLページを作成することも可能です。例えば、
ユーザーの入力に応じて変化する、サーチエンジンの検索結果の表示や、データベースからデータを取
得しての、オンラインバンキングの残高照会ページや時々刻々と変化する株価情報のページなどの作成
が可能です。
その他、同一のクライアントからのアクセスを結びつけるセッション情報をサーブレットから利用・制御しま
す。セッションについては二頁後で説明します。
JavaBeansやEJBと連携することなく、サーブレット内部でビジネスロジックを実行したり、直接データベー
ス・アクセスを行うこともできます。また、JSPにHTMLページの作成を依頼せず、サーブレット内部でクライ
アントに返答するHTMLページを作成することもできます。しかし、機能に応じて、プログラムの分割を行わ
ないと、同じロジックが複数のサーブレット内に現れ、バグの原因となりやすいなど、開発・保守性が大きく
劣ります。また、プログラムの再利用なども困難となります。
15
WebSphere Application Server 概説
サーブレットのライフサイクル
サーブレットの起動時にinit()メソッドが1度だけ呼び出される
サーバーの初期化時
最初のクライアント・リクエスト時
サーブレットの再ロード時
クライアントからのリクエスト毎にservice()、もしくはdoGet()、doPost()メソッドが呼
び出される
サーブレットの終了時にdestroy()メソッドが1度だけ呼び出される
サーブレット起動
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
リクエスト、レスポンスを
public class SimpleServlet extends HttpServlet{ 抽象化したオブジェクト
初期化
(init)
リクエスト
public void init(ServletConfig config) throws ServletException {
}
サービス処理
public void service (HttpServletRequest request,
(service)
HttpServletResponse response ) throws ServletException, IOException{
String myName = request.getParameter("myName");
response.setContentType("text/html");
パラメータの取得
PrintWriter out = response.getWriter();
out.println("<head><title> Servlet Sample </title></head>");
out.println("<body><h1>" + "hello, " + myName + "</h1></body>");
}
public void destroy(){
}
要求待ち
WAIT
レスポンス
終了処理
(destroy)
サーブレット消滅
レスポンスの生成
}
サーブレットにはクラスのロードからインスタンスの消滅までのライフサイクルがあります。
Javax.servlet.Servletインタフェースに定義されているinit(),service(),destroy()メソッド
がライフサイクルのそれぞれの処理に対応しており、それらを実装することでサーブレッ
トを作成します。
init()はサーブレットがロードされたとき1度だけ呼び出されます。init()は、サーブレットの
初期処理に利用されます。例えば、サーブレット使用するファイルを事前にメモリーに展
開するなどです。
service()はリクエストごとに呼び出されます。service()には、クライアントからのリクエスト、
クライアントへのレスポンスを抽象化した2つのオブジェクトが渡されます。リクエスト・オ
ブジェクトからパラメータを取得して解析し、パラメータに応じてビジネス・ロジックを実行
し、そして、レスポンス・オブジェクトから取得したPrintWriterに結果をWebページとして
出力します。出力されたWebページは、HTTPサーバーを通じて、クライアントに返され
ます。
destroy()はサーブレットがアンロードされるときに呼び出されます。destroy()では、サー
ブレットの後処理を行います。データの保存やログの作成などです。
このコード例はJSPを用いずにサーブレットにてView（表示）部分も行っている最も単純
な例です。
16
WebSphere Application Server 概説
セッション・トラッキング
クライアントが送る一連のリクエストをトラッキング
クライアント／サーバー間でセッションIDを送受信
CookieまたはURL再書き込みを使用
複数画面にまたがるデータを、セッション・オブジェクトに保持
例： ショッピング・カートに入れた商品を後の画面で参照する
セッション・オブジェクトはDBに格納可能（WASの持続セッション機能）
セッション・マネージャーがセッション管理を行う
アプリケーション・サーバー
セッションの取得
HttpServletRequest.getSession()
初回のリクエスト時、
セッションIDが戻る
Cookie
SessionID=xxxxx
クライアントPC
HttpSessionオブジェクト
Servlet_A
SessionID=xxxxx
処理結果の保存
setAttribute("名前",ｵﾌﾞｼﾞｪｸﾄ)
Webブラウザー
SessionID=yyyyy
以降のリクエストで
セッションIDを送る
Cookie
SessionID=xxxxx
Servlet_B
処理結果の取得
getAttribute("名前")
セッション
DB
SessionID=zzzzz
セッション
マネージャー
HTTPプロトコルはステートレスなプロトコルです。つまり、クライアントからWebサーバーへのリク
エストがあるたびに、クライアントとサーバー間でコネクションを確立し、リクエストに対するレスポ
ンスが行われるとコネクションが切断されます。このため、通常はWebサーバーに対する複数の
リクエストが同一クライアントから送信されたものであるかどうかをサーバー側で判断することがで
きません。
しかし、電子商取引サイトで提供されている「ショッピング・カート」アプリケーションなどでは、クラ
イアントからのリクエストを特定のユーザーと結びつける必要があります。これが実現できなけれ
ば、アプリケーションはある買い物客の選んだ商品を謝って別の買い物客のショッピング・カート
にいれてしまうかもしれません。この際に必要となるのが、同一ブラウザー、同一ユーザーからの
複数のリクエストを関連付けて管理する仕組みです。この仕組みがセッションです。現在では
Cookie（クッキー）あるいはURL再書き込みという方法によってセッション・トラッキングが可能と
なっています。
○Cookie
Webサーバーがクライアントを識別するための仕組みのひとつで、ブラウザー側でデータを保管
する仕組みです。この中にサーバーがセッションIDをセットします。
○URL再書き込み
リクエストの際URLの後にセッションIDを付加して送信する方法です。Cookieが使用できないと
きに有効な手段ですが、URLの後ろにセッションIDが見えてしまうという欠点もあります。
セッション・トラッキング機能により、同一のクライアントからの要求に関する情報は、セッション・オ
ブジェクトに格納され、後の画面で参照することが可能となりました。
WASでセッション管理を行うコンポーネントはセッション・マネージャーと呼ばれます。セッション・
マネージャーに対する設定は管理コンソールから行うことができます。
17
WebSphere Application Server 概説
JSP概要
JSP (JavaServer Pages) とは
サーバーサイドでのスクリプティング技術
ダイナミックなWEBコンテントを作成するJ2EEのテクノロジー
JSPの役割
サーブレットよりも、HTML生成が得意
サーブレットやEJBからデータを受け取り、クライアントにHTMLページ送付
プログラム・ロジックと独立してページ作成可能
Webブラウザー
宣言
表示
<HTML><HEAD>・・・
<HTML><HEAD>・・・
<html>
<head><title> JSP Sample </title></head>
<%!
String myName;
%>
<%
myName = request.getParameter("myName");
%>
<body>
スクリプレット
<h1> Hello,
<%=
myName
%>
</h1>
</body>
</html>
View
Servlet
EJB または
JavaBeans
JSP
JSPはJavaServer Pagesの略です。
JSP は、サーバー・サイドで稼動するスクリプティング技術です。 JSPはHTML形式の
ファイル内にJSPの仕様として定められた独自のタグでJavaのコードを追加記述したも
のです。 JSPファイルをアプリケーション・サーバーのWebコンテナーで実行することに
より、静的なHTMLタグと動的に作成されたHTMLタグを合わせて、動的なページを生
成します。
JSPのソースファイルの表現方法は、通常の静的なHTMLと、動的なコンテンツをひとつ
のページに混在させることができます。動的に表示する部分のみ（例えば、ようこそ○○
さんの部分のみ）<％ではじまり、％>でおわるJSPのタグを挿入し、記述します。このよう
な特徴があるため、JSPでクライアントへの返答ページを作成するほうが、簡単で、読み
易くなります。つまり、JSPはHTMLの生成を得意とするので、サーブレットやEJBから
データを受け取り、そのデータをクライアントにHTMLページとして送付する部分で使用
されます。また、JSPは、プログラム・ロジックとは無関係にWebページをデザインするこ
とができます。
18
WebSphere Application Server 概説
JSPの動作フロー
WebSphere Application Server
（２）JSPファイルがリクエストされると、JSPプロセッサーが処理を開始
JSPファイル
（１） クライアントからのリクエスト
(2.1)初回のリクエストであれば、
JSPファイルを静的なコンテンツとJavaソースに分割
--------------------------------------------------------------------------------
静的コンテンツ Javaソース(動的)
（３）サーブレットは静的コンテンツに
処理結果をインクルードしながら、
レスポンスを生成
-------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------
(2.2）コンパイルして、クラス・ファイルを生成
JVM
（４） クライアントへのレスポンス
生成されたクラス・ファイルは一時ディレクトリに保管され、再利用される
JSPのライフサイクルは以下のとおりです。
（1）クライアントからのJSPファイルのリクエストをWebコンテナーが受け取ります。
（2）そのリクエストはJSPプロセッサーに渡されます。
（2.1）初めてJSPファイルがリクエストされた場合、またはJSPファイルのコンパイル済み
クラスファイルが見つからない場合は、JSPコンパイラーはそのJSPファイルのJavaソー
スファイルを生成します。
（2.2）さらにコンパイルしてJavaソースファイルを生成します。
JSPプロセッサーはJavaソースとクラスファイルをJSPプロセッサー･ディレクトリーに置き
ます。
（3）Webコンテナーはサーブレットのインスタンスを作成し、その後のJSPに対する要求
はすべてサーブレットのそのインスタンスによって処理されます。
（4）出力結果は、HTTPサーバーを通じてWebクライアントに返されます。
○JSPプロセッサー
各JSPファイルからサーブレットを作成して、コンパイルを行います。JSPファイルごとに、
javaファイル、classファイルの２つのファイルが生成されることになります。
・javaファイル
JSPファイルから生成されたサーブレットのソース･ファイル
・classファイル サーブレットがコンパイルされ生成されたクラス・ファイル
19
WebSphere Application Server 概説
JavaBeans
再利用可能なソフトウエアコンポーネント
MVCではModel(ビジネスロジックを記述する部分)に割りあてられる
ビジネスロジックの処理結果をJavaBeanに保存し、JSPはその保存さ
れたデータを使用
public
開発ツールで扱いやすい
publicclass
classEmployee
Employee{ {
private
privateString
Stringname
name==null;
null;
private
privateint
intsalary
salary==0;0;
private
privateint
intbonus
bonus==0;0;
サーブレット
Model
Webブラウザ
public
publicint
intgetSalary()
getSalary(){ {return
returnsalary;}
salary;}
public
publicvoid
voidsetSalary(int
setSalary(intsalary)
salary){ {
this.salary
this.salary==salary;
salary;
}}
public
publicint
intgetBonus()
getBonus(){ {
…
… (以下略)..
(以下略)..
JSP
JavaBeans
JavaBeansとは、ビジネスロジックを記述したJavaクラスです。再利用することにより、シ
ステム開発の省力化や効率化を目的としています。JavaBeansはJavaBeansを呼び出
すサーブレットなどのプログラムと同じアプリケーション・サーバー、具体的にはWebコン
テナで稼動し、処理結果を保存します。特徴のひとつとして開発ツールで扱いやすいこ
とがあげられます。
JavaBeansの作り方は厳格に決められているので、これに従ってJavaプログラムを作成
することにより、標準化を図ることができます。
20
WebSphere Application Server 概説
EJB概要
EJB (Enterprise Java Beans)とは
分散環境で利用できる、ビジネスロジックを記述した再利用可能なコ
ンポーネント
他のマシンのサーブレットやEJBからのリクエストにも応答
3種類のEJB
セッションBean：サーブレットや他のEJBから呼び出され、処理を実行し、結果を返す
エンティティーBean：データベースのデータをオブジェクト化し、利用しやすくする
メッセージ・ドリブンBean：メッセージ・キューに到着したデータの受け付け
Servlet
データベース
JSP
Model
他の
EJB
EJB
メッセージ・
キュー
EJBは、Enterprise JavaBeansの略です。EJBは分散環境で利用できる、ビジネスロ
ジックを記述した再利用可能なコンポーネントです。データベースなどの既存のシステ
ムとの連携したビジネスロジックなどを実行します。EJBは、他のマシンのサーブレットや
EJBからアクセスされる分散環境での使用、一度作成したものを他の環境で再利用する
ことを意識したプログラムです。リモート環境からアクセスできるようにするため、呼び出
し方法に厳密な規則があります。しかし、その規則に従うことにより、分散環境での使用、
再利用が実現され高い生産性とポータビリティを享受することができ、管理のしやすい
システム構築が可能となります。
EJBには3つの種類があります。
○セッションBean
ビジネス・ロジックを実装します。状態の有無でステートレスとステートフルの２種類存在
します。
○エンティティーBean
セッション終了後も永続方式（預金口座のイメージ）の違いでBean管理パーシスタンス
とコンテナ管理パーシスタンスの２種類存在します。
○メッセージ・ドリブンBean
Java Message Service を利用した非同期通信を実現します。
尚、EJBはEJBコンテナ上で稼動し、EJBコンテナの提供するトランザクション管理や
データベースとの接続管理などの機能を利用することができ、生産性が向上します。
21
WebSphere Application Server 概説
JDBC
JDBC（ Java Database Connectivity ）とは
Javaアプリケーションからデータベースを操作するAPI
Client Code Sample
ds = (DataSource) ctx.lookup(dsJNDI);
Javaアプリケーション
JDBC API
JDBCドライバマネージャ
JDBCドライバAPI
JDBCドライバ
conn = ds.getConnection();
stmt = conn.prepareStatement
(“select a,b from ...”);
rs = stmt.executeQuery();
while (rs.next()) {
resultString[1] = rs.getString(1);
}
rs.close();
DBMS
stmt.close();
DataSourceの
DataSourceの
lookup
lookup
接続の取得
接続の取得
ステートメント準備
ステートメント準備
クエリー実行
クエリー実行
DB
DB
結果取得
結果取得
関連オブジェクト
関連オブジェクト
close
close
conn.close();
JDBCとはJava Database Connectivityの略で、Javaアプリケーションからデータベースを操作するAPIのことです。
JDBCは階層構造をとり、Javaプログラムから使用するJDBCドライバー・マネージャとDBMSに依存するJDBCドライ
バーとを分けます。これによりデータベース製品に依存しないJavaプログラムを作成できるようになります。
JDBCの構成要素としては次のものがあります。
○アプリケーション
ユーザー作成のデータベース・アクセス・プログラムです。
○JDBCドライバー・マネージャー
アプリケーションとJDBCドライバーの間にはいって１つまたは複数のJDBCドライバーを管理する役割を持つ部分で
す。この部分はJDKのコア・クラスとして提供されています。
○JDBCドライバー
実際にデータベースへの接続やその後のデータベース処理を直接行う部分です。
この部分はIBM,Oracleなどのデータベース・ベンダーがJDBCのAPIを実装したものを提供します。
○JDBC API
アプリケーションからJDBCドライバー・マネージャーを経由してJDBCドライバーを呼び出し、クエリーを実行したり、
結果を受け取ったりするためのインターフェースを規定したAPIです。
JDBCという言葉を狭い意味でとらえた場合、JDBC APIを指します。
○JDBCドライバー API
JDBCドライバー・マネージャーからJDBCドライバーを取り扱うためのインターフェースを規定したAPIで、JDBCドライ
バーを作成する際に従うAPIです。通常のアプリケーション開発者はこのAPIを意識しません。
○DBMS
共有データとしてのデータベースを管理し、データに対するアクセス要求に応えるソフトウエア。
○データソース
データベースに接続するために必要な情報（データベース名、JNDI名、データ･ソース・ヘルパーの型、ユーザーID、
パスワード）を指定するための定義情報です。
22
WebSphere Application Server 概説
その他WASがサポートするAPI
SDO (Service Data Objects)
多様なデータストアーに対して統一されたデータアクセスを提供
JSF (JavaServer Faces)
Webアプリケーションのユーザー・インターフェースの開発を容易に
するための標準フレームワーク
WebSphere Extentions
J2EEを拡張するIBM独自の追加API
WebSphere Application Serverをサポートするその他のAPIには、以下のものがありま
す。
・SDO
・JSF
・WebSphere Extentions
23
WebSphere Application Server 概説
SDO (Service Data Objects)
様々なデータソースの違いを隠蔽する、データに対する統一的なプログ
ラミングモデルを提供するもの。
RDB、XMLファイル、Webサービス、JCAリソースアダプター、JMSなど
IBMとBEAを中心にJSR235で策定中
http://jcp.org/en/jsr/detail?id=235
SDO Core
APIs
Custom
Mediator
Access APIs
Data APIs
Metadata Access APIs
Metadata APIs
File
JDBC
Mediator
Access APIs
Data APIs
Metadata Access APIs
Metadata APIs
Data
Base
EJB
Mediator
Access APIs
Data APIs
Metadata Access APIs
Metadata APIs
Data
Base
Application
…
…
SDO(Service Data Object)はIBMとBEAを中心にJSR235で策定中のデータアクセス
の新しい仕様です。様々なデータソース(RDB/XML/JMSなど）の違いを隠蔽し、データ
に対して統一的なアクセスを実現するプログラミングモデルです。RDBやXMLファイル
などのデータをSDOの規格で統一されたデータ形式に変換することで、接続先のリソー
スに左右されないデータアクセスを実現することを目的としています。
Spec等は以下のサイトを参照してください。
http://www-106.ibm.com/developerworks/library/j-commonj-sdowmt/
○Mediator
メッセージング・パスを通過するメッセージを操作します。
○Data Graph
データソースとクライアント間のデータ送受信の単位です。Data Objectのツリー構造に
おける最上位のData Objectを保持します。また、Data Objectに対して変更があった場
合の変更情報（Change Summary）も含みます。Data GraphはData Mediator
Serviceによって作成されます。
24
WebSphere Application Server 概説
JSF (JavaServer Faces)
ユーザー・インターフェース構築用フレームワーク
JSR127で仕様が策定
EoD(Ease of Development)の向上
WAS V6からJSF1.0をサポート
J2EEには、短期間・高品質なWebアプリケーションの開発を支援するためのフレーム
ワークが数多く存在しています。その中でWebアプリケーションのユーザー・インター
フェースの開発を容易にするためのフレームワークとして、J2EEの標準として採用され
たフレームワークがJSFです。JSFはJCP(Java Community Process)においてJSR127として仕様が策定されています。
JSFの目的の１つはEoDを向上させることです。JSFを採用した統合開発環境を使用す
るWebアプリケーションの開発者はプログラミングをほとんど行う必要はありません。統
合開発環境の中で部品の配置やプロパティの設定を行い、ユーザー独自の処理を一
部ロジックとして記述するだけでユーザー・インターフェースの開発が行えます。
25
WebSphere Application Server 概説
WebSphere Extensions
J2EE1.4のプログラミングモデ
ルの拡張
プログラミングやデプロイメント
の効率化
表１
Business Object Model
Application Profiling
Dynamic Query
Business Process Model
Activity Session
Next generation applications
Asynchronous Beans
Startup Beans
Object Pool
Scheduler
Work Area
WebSphere Extensionsは、エンタープライズレベルのアプリケーションを作成するための機能をIBMがJ2EE仕様を
超える形で独自に提供しているものです。従来はWASのエンタープライズ版の機能として提供していましたが、WAS
V6では、Express版からWebSphere Extensionsがサポートされるようになりました。Choreographyなどのワークフ
ロー機能は引き続き、WebSphere Process Server でサポートされます。表1は、WASの各バージョンにおける、
WebSphere拡張機能の対応を表しています。
■Business Object Model
ビジネス・オブジェクト・モデル拡張は、ビジネス・オブジェクト（例えばEJB等）を扱う上での拡張です。
・Application Profiling アプリケーション・クライアントに応じてEntityのアクセス・インテントを設定することができます。
EJB QLの機能拡張を実現
・Dynamic Query
■Business Process Model
ビジネス・プロセス・モデル拡張は、アプリケーション・サーバーに対するプロセスやサービスといった機能を拡張しま
す。
・Activity Session
従来のローカル･トランザクション／グローバル･トランザクションに次ぐ第三のUOW（Unit Of
Work）を提供します。
■Next generation applications
ネクスト・ジェネレーション・アプリケーション拡張は、その他の細かな機能の総称です。現在のJ2EE環境の上で、最
新の機能を提供することにより、アプリケーション開発やパフォーマンスの面での大きなメリットを享受できます。
・Asynchronous Beans 非同期（マルチスレッド）プログラミングのための仕組みです。
・Startup Beans
アプリケーション（EAR）の起動と終了時に、自動的に呼び出されるstateful session beanで
す。
・Object Pool
オブジェクトをプールして再利用することで、メモリ効率の向上を目指す仕組みです。
・Scheduler
特定の時間および間隔でタスクを実行するための機能です。
・Work Area
アプリケーション・コンポーネント間で（引数やメソッドの戻り値を使わずに）情報を伝達するため
の仕組みです。
26
WebSphere Application Server 概説
構成の基本
アプリケーション・サーバーを導入後、管理者が構成しなければいけない基本的な要素とその方法につ
いて説明します。
27
WebSphere Application Server 概説
システム管理ツール
WebSphere Application Server は以下のシステム管理ツールを提供
管理コンソール
システム管理機能を提供するグラフィカルインターフェース
正体はエンタープライズ・アプリケーション
ブラウザでアクセスする
スクリプト (wsadmin)
コマンド・インタープリター環境。
スクリプト言語で管理操作を対話的に実行できる
スクリプト言語プログラム作成、読み込ませて実行することも可能
コマンド
オペレーティング・システムのコマンド行プロンプトから実行する
サーバーの開始と停止や、サーバー状況の確認など
プログラミング
業界標準の Java Management Extensions (JMX) 仕様に基づいて管理プログラムを開発す
るための Java プログラミング・インターフェースをサポートWASで提供されているすべての管理
ツールは、JMX に従って作成されている
WebSphere Application Serverは、アプリケーション・サーバーの構成・管理を行うた
めのツールを提供しています。
管理コンソールは、WAS を管理するためのグラフィカルなWebブラウザー・ベースの管
理コンソールです。管理サーバー下の全トポロジーについて定義／参照をふくむすべ
ての操作が可能です。管理コンソール用のアプリケーションは、他のサンプルアプリ
ケーションと同様にEARファイルの形式で導入時にセットアップされます。
Wsadminツールはスクリプト言語を使用して対話的な管理をサポートします。シェル
（wsadmin.sh）またはバッチファイル（wsadmin.bat）として存在します。
使用頻度が高い主な管理用オペレーションについて、いくつか独立したコマンドとして
提供されています。また、コマンドの実行結果は、＜コマンド名.log＞ファイルに出力さ
れるため、エラー時などにはログにて検証することができます。
WAS におけるシステム管理は、JMX（Java Management eXtentions）ベースに構築
されています。WAS が標準で提供する管理ツール群は、JMXを使用して実装されてい
ます。このため、さらにシステム運用・管理者は、JMXのAPIを使用し拡張することで、独
自の管理システムを組み込むことも可能になります。
28
WebSphere Application Server 概説
データベース接続概要
アプリケーションからデータベースに接続するには
様々な情報が必要
データベースの種類は？
データベースの場所は？
データベースの名前は？
接続ユーザーIDとパスワードは？
Webクライアント
WAS
WAS
....
........
....
データベース
データベース
接続
.... 接続
........
....
データベース固有の情報
＝アプリケーションコード内に
記述するとポータビリティ低下
データベース
データベース
接続
設定
アプリケーション
アプリケーションからデータベースに接続するには、データベースの種類や名前、接
続に必要なパスワードなど、様々な情報が必要です。これらの情報はデータベース固
有の情報であり、アプリケーション・コード内に記述してしまうと、接続先データベースの
情報が変更した場合にコードを変更しなければならず、ポータビリティが低下します。そ
こで、これらの情報をWAS上に設定し、アプリケーションから参照できるようにします。
29
WebSphere Application Server 概説
データベース接続設定
WASからデータベースにアクセスするためには、以下の2つの設定が必要
①JDBCプロバイダーの作成
各データベースベンダーが提供するJDBCドライバーをWAS上に設定
データベースの種類ごとに作成
②データ・ソースの作成
JDBCプロバイダー上に、データベースに接続するために必要な情報（データ
ベース名、アクセスユーザー名、パスワード等）を設定
1データベースごとに作成
WAS
DB2用JDBCプロバイダー
Oracle用JDBCプロバイダー
DB2用JDBCドライバー
Oracle用JDBCドライバー
UserDB1用
UserDB2用
データ・ソース データ・ソース
UserDB3用
UserDB4用
データ・ソース データ・ソース
DB2
Oracle
UserDB1
UserDB2
UserDB3
UserDB4
WAS上で稼動する開発者の作成したプログラム(サーブレットやEJBなど)からDB2や
Oracle等のデータベースにアクセスするためには、以下の2つの設定をWAS上で行う
必要があります。
①JDBCプロバイダーの作成
データベース製品に依存しない共通のJDBCのAPIを使用して、各種データベースに
アクセスできるように、各データベースベンダーが提供するJDBCドライバー（拡張子が
jarやzipのファイルで提供されます）をWAS上に設定します。これはDB2、Oracleなどの
データベースの種類ごとに作成します。
②データ・ソースの作成
JDBCプロバイダー上に、個々のデータベースに接続するために必要な情報（データ
ベース名、アクセスユーザー名、パスワード等）を定義します。1つのデータベースに対
して1つのデータ・ソースを作成します。
上記の図では、複数のJDBCプロバイダーを作成し、複数のデータ・ソースを作成して
いますが、1つのデータベースのみにアクセスする場合は1つのJDBCプロバイダーを作
成し、その中に1つのデータ・ソースを作成すれば、充分です。
30
WebSphere Application Server 概説
セッション管理設定
セッション・マネージャーがセッション管理を行う
セッション・マネージャーの設定は管理コンソールから
メモリー内で保持できる
セッションの最大数
上で指定した最大数を
超えた時の動作
セッションが使用されなくなってか
ら無効になるまでの時間を指定
Cookie、URL再書き込み、
SSL IDのどれを使うか
WASでセッション管理を行うコンポーネントはセッション・マネージャーと呼ばれます。セッション・マネージャーに対す
る設定は管理コンソールから行うことができます。設定はアプリケーション・サーバー（Webコンテナー）単位、エン
タープライズ・アプリケーション単位、Webモジュール単位の３つのレベルで設定できます。デフォルトでは各レベル
の設定は上位のレベルの設定を引き継ぎます。例えば、 Webコンテナー内のアプリケーションおよびそのWebモ
ジュールは各レベルで変更を加えない限り、Webコンテナーの設定を引き継ぎます。
WASの管理コンソールの「セッション・トラッキング・メカニズム」の項目でCookie、URL再書き込み、SSL ID（※1）のう
ちどれを使ってセッショントラッキングを行うかを指定することができます。デフォルトではCookieのみを使用する設定
になっています。URL再書き込みを選択した場合は該当するアプリケーションのコードがURL再書き込みに対応して
いることが前提です。複数の方法を指定することもできます。CookieとURL再書き込みを併用するとユーザー側で
Cookieが使用できる設定になっている場合はCookieが優先され、それ以外ではURL再書き込みが使われます。ま
た、SSL IDは他の２つの方法より優先的に使用されます。
「Cookieを使用可能にする」のリンクをクリックすると、Cookieのさらに詳細な設定を行うことができます。ここでは特定
のURLにCookieを送らないようにするなどの設定ができます。
注）管理アプリケーションを実行するサーバーではCookieを使用不可にしないでください。使用不可にするとサー
バーを再起動した後に管理アプリケーションが機能しなくなります。
※1 SSLで通信する場合は、Webサーバーが割り振るSSL IDをセッションIDの代わりに使用することができます。た
だし、サポートされているのはIBM HTTP ServerおよびiPlanet Webサーバーのみです。
「メモリー内の最大セッション・カウント」ではメモリー内に保持できるセッションの最大数を指定します。その上の「オー
バーフロー」の項目にチェックを入れた場合は指定された最大数を超えるとメモリー内に新たにセッションを格納する
領域がとられます。この場合、無限にセッションが作成できてしまいますのでご注意ください。チェックをはずした場合
は最大数を超えてセッションを張ろうとするとアプリケーションにエラーが返ります。ただし、後述する「セッション・パー
シスタンス」を使用する場合は別の意味になります。
「セッション・タイムアウト」の項目ではセッションが使用されなくなってから無効になるまでの時間を設定します。セッ
ションがタイムアウトになるとサーバーが保持していたセッション・オブジェクトが破棄され、メモリが解放されます。
「セッション・タイムアウト｣の項目はパフォーマンス・チューニングの観点からも重要な項目です。
31
WebSphere Application Server 概説
セキュリティ
WASが提供するセキュリティの仕組み
J2EEセキュリティ
認証
アクセス制御
グローバルセキュリティ
サーバーの停止にユーザーID、パスワードが必要
管理コンソール起動時、ユーザーID、パスワードが必要
グローバルセキュリティ有効
認証
WebリソースやEJBにアクセスするために、セキュリティ・ポリシーやサービスを提供しま
す。
○J2EEセキュリティ
・認証
リソースを要求するユーザーが誰であるか、たしかに本人であるかを確認します。もっと
も一般的な手法は、ユーザーIDとパスワードの照合によって審査します。
・アクセス制御
認証されたユーザーが、その要求するリソースにアクセスする権限をもっているかを判
定します。WebSphereSecurityにおけるリソースとは、Webクライアントの場合は、
Servletのメソッド（HTMLファイルはFileServletのメソッドがリソースとなる）、EJBクライア
ントの場合はEJBのメソッドになります。
○グローバルセキュリティ
WASにはセル内全体で有効となるグローバルセキュリティという機能があり、これを有効
にすると管理ツールを使用する際に認証が行われるようになります。この設定を行えば、
WASの管理者ではないユーザーに管理ツールを使用されることはなくなります。アプリ
で設定してあるものについては制御します。またサーバーを始動・停止する際にも認証
が行われるようになります。
32
WebSphere Application Server 概説
アプリケーションの実行
33
WebSphere Application Server 概説
開発から実行までの流れ
アセンブリ
作成
コンポーネント・プロバイダーが
Ｊ２ＥＥモジュールを作成
J2EE
モジュール
アプリケーション・アセンブラーが
Ｊ２ＥＥモジュールを組み合わせて
Ｊ２ＥＥアプリケーションを構成
デプロイ
J2EE
デプロイヤーがＪ２ＥＥ
アプリケーションをデプロイ
アプリケーション
【新規アプリ】
Rational Application Developer
・一般的なデプロイ方法
WebSphere Application Server
JSP
Servlet
HTML
EJB
Webモジュール
ディプロイメント・
ディスクリプター
EJBモジュール
ディプロイメント・
ディスクリプター
ディスクリプター
JARファイル
APP
Client
・ホットデプロイ
・Fine Grained Update
WARファイル
JARファイル
EJB
【更新アプリ】
E
A
R
フ
ァ
イ
ル
稼動確認
（URL実行）
アプリケーション
クライアント・モジュール
ディプロイメント・
ディスクリプター
J2EEアプリケーションをWebSphere Application Server で動かす手順は、次のとおりです。
1）プログラムの作成
まず、Rational Application Developer（以下、RAD）等の開発ツールを用いてプログラムを作成します。
コンポーネント・プロバイダーは、EJB、JSP 、サーブレット、HTMLなどのコンポーネントを、それらをサ
ポートするコンテナーの J2EE モジュールに作成します。
2）アセンブリ
これらのプログラムファイルやそれらをまとめて作ったモジュールをEARファイルにパッケージし、デプロイ
メント・ディスクリプターを作成することをアセンブリといいます。EARファイルの中にはプログラムファイル
だけでなく、デプロイメント・ディスクリプターも含まれます。デプロイメント・ディスクリプターとは、デプロイ
時に変更可能なプログラム構成、動作に関連する情報を記述するXMLファイルです。。
3）WebSphere Application Server にデプロイ
J2EEアプリケーションのデプロイとは、アプリケーション開発者が作成したEARファイルを、WASの実行
環境上に導入し、ユーザーへサービスを提供できるようにすることです。J2EEアプリケーションはJ2EE
サーバーの提供するWebコンテナーとEJBコンテナー上で稼動することを前提に作成されています。
J2EEアプリケーションをJ2EEサーバーにデプロイすることにより、J2EEアプリケーションが、J2EEサー
バーの提供する、データベース・アクセス、トランザクション管理等の共通機能(サーブレット、JDBC等の
API)を利用することができるようになります。
34
WebSphere Application Server 概説
アプリケーションの作成方法
Rational Application Developer（RAD）
RADを使用してJ2EEにそった開発をする
アプリケーションのコーディングや、デプロイメントディスクリプターにおける設
定を実施
サーブレット開発Javaエディター
デプロイメント・ディスクリプター・エディター
RADの効果
アプリケーションの設計におけるパフォーマンスの向上、生産性の向上
開発からテストの期間の短縮
＊デプロイメント・ディスクリプター（デプロイメント記述子）
-デプロイ時に変更可能なプログラム構成、動作に関連する情報を記述するXMLファイル
EARファイルとそれを構成するサーブレットやEJBはRADなどの開発ツールを用いて開
発します。
RADとは包括的な統合開発環境であり、 これを使用すると、 Web、 Java、 Web サー
ビス (サービス指向アーキテクチャー (SOA) でのサービスを含む)、 および EJB開発な
どのJ2EEV1.4 プログラミング・モデルの完全サポートにより、 アプリケーション開発をよ
り迅速に行うことができます。 Rational Web Developer for WebSphere Softwareの
機能にEJB開発・テスト機能とパフォーマンス分析ツール（プロファイリング機能）を加え、
J2EE開発者向けに設計されています。また、Rational ClearCase LT が同梱され、
Clear Case LTによるチーム開発サポートを提供します。EJBの開発およびテスト・サイ
クルの短縮を支援する、生産性の高い統合開発環境です。
これにより、アプリケーションの設計やパフォーマンスの向上、個人ベースの生産性と
チーム全体の生産性向上、開発からテストの期間の短縮などを実現することができます。
デプロイメント・ディスクリプター（DD:Deployment Descriptor、デプロイメント記述子）と
は、デプロイ時に変更可能なプログラム構成、動作に関連する情報を記述するXMLファ
イルです。これは、XML形式ファイルで各モジュールに含まれます。
35
WebSphere Application Server 概説
アセンブリ
エンタープライズ・アーカイブファイル(xxx.ear)
Webモジュール(xxx.war)
EJBモジュール アプリケーション・
クライアント・
(xxx.jar)
モジュール
設定ファイル
(application.xml
など)
サーブレット
プログラム
JSP
HTML
ファイル
ファイル
(xxx.class)
(xxx.jsp)
(xxx.html)
設定
ファイル
(web.xml
など)
(xxx.jar)
EJB
プログラム
設定ファイル
(xxx.class)
(ejb-jar.xml
など)
Application
Client
プログラム
(xxx.class)
設定ファイル
(applicationClient.xml
など)
デプロイメント・ディスクリプター
WASにアプリケーションをデプロイ（インストール）するためには、アプリケーショ
ンは上記のような構造をとる必要があります。
エンタープライズ・アーカイブファイル（EARファイル）の中にはプログラムファイ
ルだけでなく、デプロイメント・ディスクリプターも含まれており、アプリケーション
に対する様々な設定が書かれています。
これらのプログラムファイルやそれらをまとめて作ったモジュールをEARファイル
にパッケージし、必要なデプロイメント・ディスクリプターを作成することを「アセン
ブリ」といいます。
さらに詳細にEARファイルの内容を見ると、WebモジュールとEJBモジュールと
アプリケーションクライアント・モジュールとそれぞれの設定ファイルから構成され
ます。Webモジュールはクライアントからの要求の受付や返答を行うサーブレッ
ト、JSP、HTMLとその設定ファイルをまとめてパッケージングしたものです。ファ
イルの拡張子は.warであり、WARファイルと呼ばれます。EJBモジュールは、
サーブレットやJSPから呼び出され、業務ロジックやデータベースアクセス等を
行うEJBプログラムとその設定ファイルをまとめてパッケージングしたものです。
ファイルの拡張子は.jarであり、JARファイルと呼ばれます。アプリケーションクラ
イアント・モジュールは、アプリケーションクライアントをまとめてパッケージングし
たものです。ファイルの拡張子は.jarで、JARファイルと呼ばれてます。
36
WebSphere Application Server 概説
アプリケーションのデプロイ１
デプロイとは
リソースアプリケーションをサーバーにインストールしたり既にインストール
済みのアプリケーションを更新すること
リソース定義
アプリケーション・サーバー
JDBC
プロバイダー
データベース
アプリケーション・デプロイ
アプリケーション・サーバー
デプロイ
アプリケーション
（ear）
アプリケーション
（ear）
JDBC
プロバイダー
データベース
アプリケーションをサーバーに導入して稼動させるために必要な作業には、リソース定
義とアプリケーション・デプロイがあります。
リソース定義とは、アプリケーションがデータベースなどのリソースに接続するために、
サーバー側で必要な情報を設定しておくことです。
アプリケーション・デプロイとは、開発したアプリケーションをサーバーにインストールした
り、サーバーに既にインストールされているアプリケーションを更新したりすることです。
37
WebSphere Application Server 概説
アプリケーションのデプロイ２
・JDBCドライバーのクラスパス
・データソースの実装クラス
・ネイティブ・ライブラリー・パス
WAS
JDBC
Application
JDBC
Provider
Database
DataSource
・JNDI名（jdbc/SampleDS）
・データーベース名
・データ･ソース・ヘルパーの型
・ユーザーID
・パスワード
データソースをlookupするコードの一部
try{
Hashtable parms = new Hashtable();
parms.put(
Context.INITIAL_CONTEXT_FACTORY,
“com.ibm.websphere.naming.WsnlnitialContextFactory”);
initialcontext = new lnitialContext(parms);
ds1 = (DataSource)initialcontext.lookup(“java:comp/envidbc/SampleDS”);
} catch (NamingException ne) {
ne.printStackTrace();
}
アプリケーションが稼動するために必要な作業としてリソース定義があります。
JDBCはJavaプログラムからデータベースにアクセスすることを可能にします。 JDBCは、
JDBCプロバイダー上にある、個々のデータベースに接続するために必要な情報（デー
タベース名、アクセスユーザー名、パスワード等）を定義したデータソースをみてデータ
ベースにアクセスします。
図中のコードでは、lookupというメソッドにより、データ・ソース・オブジェクトを取得してい
ます。使用するデータ･ソース名が、lookupメソッドの引数となります。このlookupメソッド
の戻り値として返されたデータ・ソース・オブジェクトに対し、接続／切断／データ・アク
セスを行います。
38
WebSphere Application Server 概説
アプリケーションのデプロイ方法
【新規アプリケーション】
一般的なデプロイ方法
新規アプリケーションをデプロイする際に、アプリケーション名、デプロイ先の
アプリケーション･サーバー、Webサーバーを指定、デプロイ後はアプリケー
ション・サーバーを再始動する
【更新アプリケーション】
ホット・デプロイ
サーバー稼動中にコンポーネントを更新できる
本番のセル環境では構成情報の不整合によるリスクから非推奨
Fine-Grained Update
アプリケーションを部分的に追加 / 更新 / 削除する機能
管理コンソール
Application.ear
更新
更新
WebModule.war
FileA
FileB
更新
EJBModule.jar
デプロイとは、開発したアプリケーションをサーバーにインストールしたり、サーバーに既にインストールされているア
プリケーションを更新したりすることです。WASではさまざまなアプリケーション・デプロイ方法が提供されており、用途
や条件に応じて適切なデプロイ方法を選択する必要があります。
アプリケーションを新規で作成する場合は以下のデプロイ方法があります。
○一般的なデプロイ方法
管理コンソールを使用しアプリケーション名、デプロイ先のアプリケーション･サーバー、Webサーバーを指定しアプリ
ケーションをデプロイします。そのときインストール・ウィザードの途中で「サーバーにモジュールをマップ」というステッ
プがあります。WebサーバーがWASの管理下にある場合、アプリケーション・サーバーへの割り振りを行うプラグイン
を限定するためにはアプリケーション・サーバーだけでなくWebサーバーも選択する必要があります。これによりクライ
アントからのリクエストを受け取ったWebサーバーは、セル内で稼動する特定のアプリケーションへ割り振りを行うこと
ができます。
ターゲットとしてWebサーバーとアプリケーション・サーバーの両方を選択すると、デプロイが完了して保管するときに
自動でプラグインの再生成が行われます。
※プラグイン
受け付けたリクエストを見てサーブレットやJSPへのリクエストであると判断すると、WebSphere Application Serverへ
そのリクエストを転送します。
※プラグインの再生成
プラグインを変更などをもりこんだ新しいものに更新し、再び生成することです。
アプリケーションに更新をかける場合は以下のデプロイ方法があります。
○ホット・デプロイ
アプリケーションサーバーを停止させずにJ2EEアプリケーションを更新する機能を提供します。
○Fine grained updates
インストール済みのアプリケーションの中の変更があったファイルだけを差分としてインストールすることができるという
機能です。ファイルやモジュールといった小さい単位で更新し、必要に応じて再起動を行うことにより、デプロイメント
時のパフォーマンスの向上が期待できます。
39
WebSphere Application Server 概説
まとめ
40
WebSphere Application Server 概説
まとめ
WebSphere Application Server 登場の背景
３つのエディション Express/WAS（Base）/Network Deployment
様々なプラットフォームで稼動
プログラミングモデル
WebSphere Application Server V6 は J2EE1.4に対応
J2EEの他、SDO・JSF・WebSphere ExtensionsなどのAPIがある
構成の基本
データベース接続
セッション管理
セキュリティ
アプリケーションの実行
Rational Application Developerを使用してアプリケーション作成
アセンブリ １つのEARファイルにまとめる
デプロイ アプリケーションをインストール
41