WebLogic Server å 7 G - Oracle...2013/08/07 · 18:35 -19:25 N WebLogic Server - f ® Q þ 5O WebLogic Server - V ¥ k z4 H T c4 i ¥ - ÿ = & ³ ô - ô K Q B q » 1 * 9 å = WebLogic

Copyright © 2013, Oracle and/or its affiliates. All rights reserved. 1

第108回夜な夜な! なにわオラクル塾 WebLogic Server勉強会＠大阪

WebLogic Server勉強会へようこそ

2013年8月7日

日本オラクル株式会社


「WebLogic Server勉強会」とは By developers, for developers

– ユーザ企業、システムインテグレータ、ベンダーのそれぞれの立場を超えたWebLogic開発者同士の繋がり

– WebLogic Serverアプリケーション開発者のための勉強会

スキルアップ

– 先人の成功・失敗談を共有

開発者間のネットワーキング

– Team WebLogic: 「やっぱり、WebLogic！」コミュニティ@Facebook

– 「WebLogicつながり」の輪を広げよう！

最新情報

– Oracle Technology Network:

– http://www.oracle.com/technetwork/jp/middleware/weblogic/community/index.html


本日のアジェンダ 18:30-18:35 オープニング

18:35-19:25 「WebLogic Serverの基本を学ぶ」 WebLogic Serverのインストールからアプリケーションの起動まで一連の流れを初心者向けに説明します。WebLogic ServerとJava EEの関係、運用管理者と開発者の役割、ドメイン作成、管理サーバ・管理対象サーバの作成、サーバの起動・停止、管理コンソールの使い方、アプリケーションのデプロイメント、JDBCデータソースの設定などデモを交えて解説します。日本オラクル Fusion Middleware事業統括本部佐々木政和

19:25-19:35 休憩

19:35-20:25 「WebLogic Server活用術」これまでWebLogic Server勉強会で取り上げてきた技術テーマから注目機能のポイントを説明します。チューニング、トラブルシューティング、WLST、デプロイ、クラスタリング、データソース、Flight Recorder、JMS、CDI、JSF、JAX-RS、EJBなど、各機能や仕様内容、活用方法、注意点を解説します。日本オラクル Fusion Middleware事業統括本部佐々木政和

20:25-20:30 Q&A


次回のご案内

2013年11月予定

アジェンダ調整中

アンケートにご希望を！

再び、お目にかかれるのを

楽しみにしています。


WebLogic Serverの基本を学ぶ (前半）

2013年8月7日




以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。また、情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことはできません。以下の事項は、マテリアルやコード、機能を提供することをコミットメント（確約）するものではないため、購買決定を行う際の判断材料になさらないで下さい。オラクル製品に関して記載されている機能の開発、リリースおよび時期については、弊社の裁量により決定されます。

OracleとJavaは、Oracle Corporation 及びその子会社、関連会社の米国及びその他の国における登録商標です。文中の社名、商品名等は各社の商標または登録商標である場合があります。


アジェンダ

1. WebLogic ServerとJava EE

2. デモシナリオ

3. WebLogic Serverのインストール

4. ドメインの作成と管理サーバの起動


WebLogic ServerとJava EE


アプリケーションサーバとは？ビジネスロジックを実行するためのミドルウェア

アプリケーションサーバ

WebLogic Server

RDBMS アプリケーション (ビジネスロジック)

クライアント

(業務データ) データ

入力/操作

アプリケーションサーバの主な機能

•ビジネスロジックの実行

•リソースアクセスやトランザクション管理など

Oracle WebLogic Serverはこの機能をJava EE 仕様にもとづいて提供する


WebLogic Server

ネーミングサービス

(JNDI)

トランザクションサービス

(トランザクションマネージャ)

セキュリティサービス (セキュリティ・レルム)

LDAP ATN Auditor ATZ

メッセージングサービス (JMSサーバ)

宛先 (キュー/トピック)

データベース

アクセスサービス

(データソース

)

RDBMS

Web サーバ

Plug In


Web コンテナ EJB コンテナ

Java EE アプリケーション

JMS RMI JTA

JDBC

JAAS JNDI

Servlet JSP EJB JPA JSF

HTTP

t3

HTTP


WebLogic Serverの開発ポリシー

最新のJava SE/EE標準に、

ミッションクリティカル環境で使える品質で対応

Java SE/EE標準が未だカバーしていない、

ミッションクリティカル環境で必要とされる

拡張機能を併せて提供


開発者と運用担当者の役割

アプリケーション開発者:

– Java EE 標準仕様に則って実装を行う

APサーバが提供する拡張機能を使うかどうかを検討する

– 運用環境が固定されていれば適用できるケースもあり

WebLogic Server運用担当者:

– 開発したアプリケーションが適切に動作するようにWebLogic Serverを設定する

アプリケーションが使用するリソースは何か？

非機能要件は？


運用担当者

Web サーバ

WebLogic Server

JNDI

トランザクションマネージャ

セキュリティ・レルム

LDAP ATN Auditor ATZ

JMSサーバ

Destination (Queue /Topic)

JDB

C

データソース

RDBMS

Plug In

開発者と運用担当者のスコープ

開発者

Web コンテナ EJB コンテナ

Java EE アプリケーション


J2EE 1.3

J2SE 1.4.2

コア機能強化

•ミッション・クリティカルシステムJ2EE基盤としての機能を確立

J2EE1.4

JavaSE 5

ゼロダウンタイム

•計画外停止の最小化に加えて計画停止も最小化。厳しい運用要件にも柔軟に対応

Java EE 5

Java SE 5&6

オラクル製品との連携

•オラクルDB連携

• Enterprise Managerによる一元管理

•インメモリ技術との連携

Java EE 5&6

Java SE 6

オラクル製品との統合、サン製品との連携

• Oracle iASとの統合

• Oracle RACとの親和性強化

• Java技術（JRockit）の強化

• Sun Javaとの連携、統合

Java EE 6

Java SE 7

ミッション・クリティカル性の強化

• RAC連携強化: 耐障害性及びスループット向上

•更なる高速化

•運用管理性の強化

WebLogic 8.1

WebLogic 9.x

WebLogic

10.x

WebLogic 11g

WebLogic 12c

WebLogic Serverの歴史


WebLogic Server 製品ラインナップ WebLogic Suite

オラクルデータベース連携

• 1st target DBとしての出荷時検証

• Enterprise Manager

• Flight Recorder

• Oracle RAC連携: 高度な負荷分散機能、自律的な障害対応

ミッションクリティカル機能

• Java SE のサポート

• 無停止再デプロイ

• 自動チューニング

• クラスタリング

• インメモリ・ソリューションの統合

• リアルタイムJVM: GC停止制御

最新のJava標準に対応

• Java EE 6, Java SE 7 に対応

•高い開発生産性、長期利用、将来性

WebLogic Server Enterprise Edition



• Enterprise Manager

• Flight Recorder

• Oracle RAC連携: 高度な負荷分散機能、自律的な障害対応(Exalogicの場合)





• クラスタリング




WebLogic Server Standard Edition



• Oracle RAC連携: 高度な負荷分散機能、自律的な障害対応(Exalogicの場合)t Recorder









JDKとWebLogic Serverのインストール (WebLogic Server 12.1.2)


JDK (Java Development Kit)のインストール Java SE Development Kit 7u25のダウンロード

– http://www.oracle.com/technetwork/java/javase/downloads/jdk7-

downloads-1880260.html

– 参考：jdk-7u25-windows-x64.exe (Windows x64 90.66 MB)


Oracle WebLogic Server 12.1.2のインストール

ダウンロード

– http://www.oracle.com/technetwork/jp/middleware/weblogic/downloads/i

ndex.html

– Generic WebLogic Server and Coherence Installer (880MB)を選択

– ofm_wls_generic_12.1.2.0.0_disk1_1of1.zipファイルを解凍

インストール開始

– JAVA_HOME（JDKディレクトリ）, PATH変数を適切に設定

– java –jar wls_121200.jar起動


Oracle WebLogic Server 12.1.2のインストールようこそインストール場所

ようこそ画面で「次へ」を選択インストール・ディレクトリを


Oracle WebLogic Server 12.1.2のインストールインストール・タイプ前提条件のチェック

Coherence、デモのインストール有無インストール先環境のチェック


Oracle WebLogic Server 12.1.2のインストールセキュリティ・アップデートの指定インストール・サマリー

セキュリティのアップデートの通知、更新を希望するかどうか

インストール内容の確認


Oracle WebLogic Server 12.1.2のインストールインストールの進行状況インストール完了

100％になったら終了インストール内容の表示して終了


ドメインのポイント


ドメインとは？

WebLogic Serverの管理の単位

– WebLogic で管理される設定はドメイン単位で管理される

= 設定ファイルが作られる単位

– 論理的な区画設定なので、サーバが稼働する物理境界で区切る必要はない

原則:「同じ設定を使用するリソースはひとつのドメインで管理」


用語の確認

ドメイン … リソース管理単位 = 設定の単位

サーバ … WebLogic Serverインスタンス(=Javaプロセス)

マシン … H/W境界 (ノードマネージャを使う場合は必須)

管理サーバと管理対象サーバ

– 管理サーバ … ドメインの設定を管理する(= configにアクセス可能な) サーバ。ドメイン内に必ず1つ

– 管理対象サーバ … 管理サーバから設定情報を取得して起動するサーバ。通常は、アプリケーション、サービスのデプロイ先として使用。

ドメインはドメインコンフィグレーションウィザードで作成

サーバとマシンはドメイン内のリソースとして定義


ドメイン

マシン

マシン

クラスタ

ドメインで管理されるリソース

管理対象サーバ



アプリケーション

JMSサーバ

セキュリティ

診断モジュール

管理サーバ

JMSサーバ

JMSサーバ

JDB

C データソース

JMSモジュール

ログ etc

ログ etc

ログ etc

ログ etc

トランザクション

NM

NM

config (設定ファイル)


ドメイン構成例

シングルサーバドメイン

マルチサーバドメイン

物理サーバ

ドメイン

サーバ (管理サーバ)

APP

物理サーバ

ドメインA

サーバa (管理サーバ)

APP1

ドメインB

サーバb (管理サーバ)

APP2

物理サーバ

ドメイン

サーバb (管理対象サーバ)

APP


物理サーバX

ドメイン


物理サーバY

サーバb (管理対象サーバ)

サーバc (管理対象サーバ)

サーバd (管理対象サーバ)

APP

開発用途で使用することが多い

運用環境ではこの構成の方が多い


今回のシステム環境

管理対象

サーバ

(Server1)

管理サーバ

(AdminServer)

Web ブラウザ

HTTP リクエスト

HTTP レスポンス

WebLogicドメイン

（base_domain) Oracle データベース

管理・監視

J

D

B

C

JDBCデータソース

名前: test

JNDI名 jdbc/test


今回のシステム構成

起動モードとは

– 本番モード本番環境で使用するモード（プロダクションモード）

– 開発モード開発環境で使用するモード（自動デプロイ機能が有効になっている等の違いがある）

構成項目当資料での設定値

ドメイン名 base_domain

ドメイン起動モード本番モード

JDK Oracle HotSpot 1.7.0_25

管理サーバ名 AdminServer

管理サーバ・リッスンポート 7001

管理対象サーバ数 1

管理対象サーバ名 Server1

管理対象サーバ・リスンポート 7002

管理者ＩＤとパスワード ID:weblogic パスワード:welcome1


Configuration Wizardの実行構成タイプテンプレート

新規、既存のディレクトリを指定（デフォルト） WebLogic Server用を選択


Configuration Wizardの実行管理者アカウントドメイン・モードおよびJDK

パスワードを入力本番モードを選択、JDKの場所


Configuration Wizardの実行オプションの構成管理サーバ

管理サーバを選択サーバ名: AdminServer、ポート番号: 7001を設定


Configuration Wizardの実行構成のサマリー構成の進行状況

管理サーバの設定情報を確認し、作成処理の結果を順番に表示


Configuration Wizardの実行構成に成功しました。

管理サーバの作成が成功


サーバの起動

WebLogic ServerはJavaプロセスとして起動する

コンフィグレーションウィザードを実行するとサーバ起動スクリプトが生成される ($DOMAIN/bin ディレクトリ)

– startWebLogic.sh(cmd) … 管理サーバ起動スクリプト

– startManagedWebLogic.sh(cmd) … 管理対象サーバ起動スクリプト

$ java … weblogic.Server


WebLogic Serverの起動/停止について WebLogic Serverでは、管理サーバや管理対象サーバは、JDKのJavaコマンドを利用して起動させるため、様々な方法が利用できます。

一般的には、ドメインディレクトリ/binに存在する下表のシェルスクリプトを利用します。ノード・マネージャを利用時は、管理コンソールから起動することも可能です。

対象操作スクリプト名備考

管理サーバ起動 startWebLogic.cmd (win)

startWebLogic.sh(Unix)

本番モードでは、デフォルトでスクリプト実行途中で管理者ユーザ、パスワードの入力が必要

本番モードでは、デフォルトでスクリプト実行途中で管理者ユーザ、パスワードの入力が必要

停止 stopWebLogic.cmd (win)

stopWebLogic.sh(Unix)


起動 startManagedWebLogic.cmd (win)

startManagedWebLogic.sh (Unix)

第1引数に管理対象サーバ名が必要デフォルトでスクリプト実行途中で管理者ユーザ、パスワードの入力が必要。

停止 startManagedWebLogic.cmd (win)

startManagedWebLogic.sh (Unix)


サーバの起動スクリプト

setDomainEnv.sh (cmd)

– ドメイン環境設定

MEM_ARGS

USER_MEM_ARGS

JAVA_OPTIONS

– Java/WLSオプション指定

起動順 (停止は逆順)

1. 管理サーバ

2. 管理対象サーバ

CALL

CALL

ドメイン環境設定スクリプト

管理対象サーバ起動スクリプト

管理サーバ起動スクリプト $ ./startManagedWebLogic.sh <server_name> <admin_url>

server_name … 起動する管理対象サーバ名

admin_url … 管理サーバのURL (ホスト名, ポート番号)


ドメイン

マシン

管理サーバと管理対象サーバ

マシン

設定ファイル

server.log domain.log


MBean


MBean

server.log

server.log

管理サーバ

管理コンソール

(consoleApp)

MBean

設定変更

起動時に読込

起動時に設定を取得

ドメインログ転送

更新・監視

更新・監視


WebLogic Serverのログファイル

サーバログ

– WebLogic Server上で動作するアプリケーションやサービス(サブシステム)

の情報を記録するログ。各サーバが出力

– $DOMAIN/servers/<サーバ名>/logs/<サーバ名>.log

HTTPログ

– サーバが処理したHTTPリクエストのログ(アクセスログ)。各サーバが出力

– $DOMAIN/servers/<サーバ名>/logs/access.log

ドメインログ

– サーバログを特定のフィルタ条件で集約したもの。管理サーバのみが出力

– $DOMAIN/servers/<管理サーバ>/logs/<ドメイン名>.log


管理サーバの起動

DOMAIN¥startWebLogic.cmd (UNIXの場合は、startWebLogic.sh) を実行します。

管理者ユーザＩＤとパスワード入力が求められるので、設定した内容に基づいて入力します。

下記のようなメッセージが表示されることを確認します。

<日時> <Notice> <WebLogicServer> <BEA-000360> <Server が RUNNING モードで起動しました。>


サーバの起動のポイント

WebLogic Serverは Java プロセスとして動作する

起動スクリプトはコンフィグレーションウィザードで生成される

– 必要に応じてカスタマイズ

起動順は、管理サーバ → 管理対象サーバの順

– 停止は逆順


管理コンソール管理コンソールは管理サーバにだけデプロイされる管理用Webアプリケーション

http://<hostname>:<port>/console * 自動的にデプロイされるので明示的なデプロイは不要


その他の管理ツール

コマンドラインツール

– WLST … 管理コンソール, コンフィグレーションウィザードの機能を併せ持つコマンドラインツール。 Jythonベース

– weblogic.Deployer … アプリケーションデプロイメントツール

– weblogic.Admin (非推奨)



<Insert Picture Here>

WebLogic Serverの基本を学ぶ

(後半）日本オラクル株式会社 2013年8月7日

第108回夜な夜な! なにわオラクル塾

WebLogic Server勉強会＠大阪

Copyright© 2013, Oracle. All rights reserved. 2

以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。また、情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことはできません。以下の事項は、マテリアルやコード、機能を提供することをコミットメント（確約）するものではないため、購買決定を行う際の判断材料になさらないで下さい。オラクル製品に関して記載されている機能の開発、リリースおよび時期については、弊社の裁量により決定されます。

OracleとJavaは、Oracle Corporation 及びその子会社、関連会社の米国及びその他の国における登録商標です。文中の社名、商品名等は各社の商標または登録商標である場合があります。

Copyright© 2013, Oracle. All rights reserved.

アジェンダ（後半）

5. 管理対象サーバの起動

6. JDBCデータソースの作成

7. アプリケーションのデプロイ、起動および停止

3


5: 管理対象サーバの起動


Oracle WebLogic Serverの管理ツール

5

• Oracle WebLogic Serverに対する各種管理操作を行うには、主に下表のツールを使用します。

• 下表以外に多くのJMX MBeanを提供しており、任意のMBeanツールで管理可能です。

管理タスクツール名概要

インストールインストーラ WebLogic Serverソフトウェアファイルの導入。

GUIモード、コンソールモード、サイレントモードをサポート

ドメイン作成 Configuration Wizard ドメインの作成で使用する。

GUIモード、コンソールモード両方サポート

ドメイン作成後の

各種構成

管理コンソール Webベースの管理コンソールアプリケーション。管理サーバが起動している場合、利用できる。

ドメインにおける各種管理操作やモニタリングを行える。

WebLogic Scripting Tool（WLST) Jythonベースで管理タスクを実行できるスクリプト・ツール。プラットフォームに依存しない。管理サーバが起動していなくても利用できる

weblogic.Deployer Javaコマンドでアプリケーション・デプロイを行うユティリティ

wlserver Antタスクドメイン作成やサーバ起動を行えるAnt Task

wlconfig Antタスクドメイン構成タスクを行えるAnt Task


管理コンソールへのログイン

6

• Webブラウザで、 http://localhost:7001/console/にアクセスします。

「ユーザ名」に「weblogic」、

「パスワードに「welcome1」を指定して「ログイン」ボタンを選択


Administration Console 12c

7


管理対象サーバの新規作成①

8

• 「サーバのサマリ」- 「コンフィグレーション」より作成処理を開始します。

②「ドメイン構造」で

「base_domain」-「環境」-「サーバ」を選択

①「チェンジセンタ」で

「ロックして編集」ボタンを選択

③「サーバのサマリ」-「構成」で「新規作成」ボタンを選択


管理対象サーバの新規作成②

9

• サーバ名とリスンポートを指定します。

③「終了」ボタンを選択

①「サーバ名」に

「Server1」を入力

②「サーバリスンポート」に「7002」を入力


管理対象サーバの新規作成③

10

• 管理対象サーバ作成を確定させます。

①「変更のアクティブ化」ボタンを選択

②「すべての変更がアクティブ化されました。再起動は不要です」のメッセージを確認


管理対象サーバの起動

11

• コマンドプロンプトを起動し、DOMAIN¥binディレクトリに移動して下記を実行し、管理対象サーバを起動します。

• > startManagedWebLogic.cmd Server1 http://localhost:7001

• 管理者ユーザＩＤとパスワード入力が求められるので、設定した内容に基づいて入力します。

• 下記のようなメッセージが表示されることを確認します。

• <日時> <Notice> <WebLogicServer> <BEA-000360> <ServerがRUNNING モードで起動しました。>


[参考] 管理対象サーバの停止方法

12

• スクリプトによる停止

• DOMAIN_HOME¥bin¥stopManagedWebLogic.cmdを使用します。

• > stopManagedWebLogic Server1

• 停止処理中、boot.propertiesが設定されていないと、管理者ユーザ名とパスワードの入力が求められるので、入力します。

• 管理コンソールによる停止

• 管理コンソールから強制的に停止させることもできます。

• 「ドメイン構造」から、「環境」- 「サーバ」- 「制御」タブを選択して、停止するサーバ名にチェックした後、「停止」ボタン- 「直ちに強制停止」を選択します。


[参考] 管理サーバの停止方法

13

• スクリプトによる停止

• DOMAIN_HOME¥bin¥stopWebLogic.cmdを使用します。

• > stopWebLogic

• 停止処理中、boot.propertiesが設定されていないと、管理者ユーザ名とパスワードの入力が求められるので、入力します。

• 管理コンソールによる停止

• 管理対象サーバと同様の手順です。

• ただし、停止実行直後から管理コンソールは使用できなくなります。


6: JDBCデータソースの作成


JDBCデータソースとは • アプリケーション実行環境（APサーバ）において、アプリケーションにデータベース接続サービスを提供する機能

• アプリケーションは、DB接続に必要な物理的な情報（DBホスト名、DBユーザIDやパスワードなど）を意識せずにデータベース接続を行える。

• 接続プールを活用することでDB接続、切断処理のオーバーヘッドを削減可能。

JDBCデータソース・サービス

接続プール

JDBCデータソース dsA

データベース

JNDIネーミング・サービス


ルックアップ

jdbc/dsA

JNDI名

jdbc/dsA

APサーバ

利用するJDBCドライバ

DB接続情報


JDBCデータソースを利用する場合のコード • 下記は、JDBCデータソースを利用してConnection オブジェクトを取得する場合のコード例。

import javax.naming.*;

import javax.sql.*;

import java.sql.*;

...(中略）

String sql = “select * from emp” //実行するSQL文

Context ic = new InitialContext(); //JNDIルックアップのための初期コンテキスト取得

DataSource ds = (DataSource)ic.lookup(“jdbc/dsA”); //データソースオブジェクト取得

Connection conn = ds.getConnection(); //コネクション取得

Statement stmt = conn.createStatement(); //Statementの作成

ResultSet rset = stmt.executeQuery(sql); //結果セットの取得

... ..(中略）

rset.close(); //結果セットクローズ処理

stmt.close(); //Statementクローズ処理

conn.close(); //コネクションクローズ処理


JDBCデータソースを利用しない場合 • アプリケーションがAPサーバのJDBCデータソース・サービスを利用せず、

JDBCドライバをロードし、そのAPIを使用してDB接続を行うことも可能。

• ただしその場合、DB接続情報や接続プールの管理をすべてアプリケーション側で管理・制御する必要がある。

データベース

APサーバ


利用するJDBCドライバと

DB接続情報の管理

接続プールの制御


JDBCデータソースを利用しない場合の例 • JDBCデータソースを利用しない場合、利用するJDBCドライバやDBの物理接続情報をアプリケーション側で管理する必要がある。

• 下記は、それらの情報をハードコーディングしてしまっている悪い例。

import java.sql.*;

...(中略）

String sql = “select empno, ename from emp” //実行するSQL文

DriverManager.registerDriver(new oracle.jdbc.driver.OracleDriver()); // 利用ドライバの指定

String url = “jdbc:oracle:thin:@host1:1521:SID”;

Connection conn =DriverManager.getConnection(url,”SCOTT”, “TIGER”); //コネクション取得

Statement stmt = conn.createStatement(); //Statementの作成

ResultSet rset = stmt.executeQuery(sql); //結果セットの取得

... ..(中略）

rset.close(); //結果セットクローズ処理

stmt.close(); //Statementクローズ処理

conn.close(); //コネクションクローズ処理


WebLogic Server 12cに含まれるJDBCドライバ

• WebLogic Server 12cでは、標準で下記のJDBCドライバを提供。

• 下表以外のJDBCドライバを利用する場合は、WebLogicに適用するCLASSPATHの先頭に追加するドライバのライブラリを追加する。

ドライバファイル名備考

Oracle Thin Driver 12c ojdbc6.jar TYPE4

MySQL5.0 JDBCドライバ mysql-connector-java-commercial-5.1.17-bin.jar

WebLogic Type4 JDBCドライバ DB2用：wldb2.jar

MS SQL Server用：wlsqlserver.jar

Informix用：wlinformix.jar

Sybase用：wlsybase.jar

DataDirectのOEM

供給

• 12.1.2ではドライバの実体は、それぞれ下記に格納されている。

• Oracle Thin Driver: ORACLE_HOME¥oracle_common¥modules¥oracle.jdbc_11.2.0

• MySQL: ORACLE_HOME¥oracle_common¥modules¥mysql-connector-java-commercial-5.1.22

• DataDirect: ORACLE_HOME¥oracle_common¥modules¥datadirect


データソース作成時に必要なパラメータ • 下表パラメータは、データベース種類に限らずデータソース定義時の共通項目

• 接続プールは、コンソールではデータソース作成後に「接続プール」タブから設定する。

項目（＊は必須項目）概要 Oracle Databaseの場合の例

データソース名＊ WebLogicでの管理名 test

JNDI名＊ JNDIツリーへのバインド名 jdbc/test

データベース種類＊ OracleやDB2など ※1 Oracle

ドライバ種類＊データベース種類に応じて指定 ※1 Oracle Thin Instance-Connection

トランザクション・オプション非XAドライバの場合に指定 1phase commit

データベース名＊データベースのID XE

ホスト名＊データベースのホスト名 localhost

ポート＊データベースへの接続ポート 1521

データベース・ユーザ名データベースユーザ名 HR

パスワードデータベースユーザのパスワード hr

ドライバ・クラス名＊ JDBCドライバのクラス名※2 oracle.jdbc.OracleDriver

URL＊ JDBC URL※2 jdbc:oracle:thin:@localhost:1521:ORCL

JDBCドライバ・プロパティ JDBCドライバ

テスト対象の表名（or SQL) 接続テストに利用する表またはSQL SQL SELECT 1 FROM DUAL

ターゲット WLSドメイン中、どのサーバで利用するか Server1

※1 コンソールの場合リストBOXで選択

※2 コンソールの場合、自動入力


接続プールの主要パラメータ • 一般的に、プール中の接続作成、縮退のオーバーヘッドを削減するため、初期容量と最大容量を同じに設定することがのぞましい。

項目概要デフォルト値

初期容量接続プール作成時に作成される接続数。接続プールに維持される最小接続数でもある。

1

最大容量接続プール中に作成可能な最大接続数 15

増分容量接続プール中に新たに接続を増加するときの量 1

予約時に接続をテストアプリケーションが接続要求を行った際に、接続の有効性をテストするか否か。（テスト対象の表名の指定が必須）

false

テスト頻度（秒）接続プール中の未使用接続に対する接続テストの実行間隔。テスト失敗時はその接続を無効化して再度接続を作成（テスト対象の表名の指定が必須）

120

アイドルプール接続を信頼する秒数

ここで指定した時間内に正常性が確認された接続のテストはスキップする。

10

縮小頻度（秒）接続プール内の接続数を縮小させるまでの間隔 900

非アクティブ接続タイムアウト（秒）

アプリケーションで使用中の接続が非アクティブの場合、ここで指定した秒数が経過すると接続プールに自動復旧する

0（無効）

接続予約のタイムアウト（秒）アプリケーションが接続要求時、接続を得るまで待機できる秒数 10

接続作成の再試行間隔（秒）接続プール中の接続作成が失敗した場合に再作成を試行する間隔 0

文タイムアウト JDBCドライバに対して実行中のSQL文をタイムアウトする時間の指定.

JDBCドライバのStatement.setQueryTimeoutのメソッド実装に依存 -1


JDBCデータソースの動作

• 下表のデータソースを前提に、WebLogicのJDBCデータソースの動作について説明します。

項目設定値

初期容量 3

最大容量 5

最小容量 3

増分容量 1

予約時にテスト False

テスト頻度 0

接続予約のタイムアウト（秒）

10

接続作成の再試行間隔 0

縮小頻度 900

項目設定値

データソース名 test

JNDI名 jdbc/test

データベース種類 Oracle(10g XE)

ドライバ種類 Oracle Thin

Service-Connection

ターゲット Server1

データソース接続プール


データソース作成

• 管理コンソール等で、「ターゲット」となるサーバ名を指定しデータソースの作成、アクティブ化を行うと、データソースが初期化され、接続プール中に「初期容量」で指定した数の接続が作成され、すぐにアプリケーションから利用可能になる。

• 「ターゲット」のサーバ指定無しでも作成・アクティブ化だけは可能。

• サーバの再起動は不要。

• データソース作成時には、データベースは利用可能状態である必要がある。

接続プール

データソース test

データソースtestを作成、

アクティブ化

WebLogic管理対象サーバ Server1

Running


アプリケーション接続要求時

• アプリケーションがデータソースを利用して接続を要求した時、データソースの接続プールに未使用接続があれば、それを「予約」してアプリケーションが利用する。

• アプリケーションは利用後接続をリリースすると、接続プールに接続が戻される。

接続プール




① getConnection()

で予約

② 使用

③ Connectionの

Close()でリリース


• 接続プール中の接続数が最大容量に達していない場合は、プール中に「増分容量」で指定した分、新たな接続が生成され、アプリケーションはそれを予約、使用することが可能。

接続プール







① getConnection() で予約

②現在接続数3、最大容量5なので

増分容量1なので、接続を1つ追加作成する ③ アプリケーションで利用可能

接続要求時に未使用接続が無い場合①


• 接続プール中の接続数が最大容量に達している場合は、接続プールに接続が戻るまで「接続予約のタイムアウト」で指定した秒数分だけ待機する。

• 「接続予約のタイムアウト」で待機しても接続を得られなかった場合、下記例外が発生する。

• weblogic.jdbc.extensions.PoolLimitSQLException: weblogic.common.resourcepool.ResourceLimitException:

• No resources currently available in pool dsA to allocate to applications, please increase the size of the

pool and retry..

接続プール






① getConnection() で予約

②現在使用数5、最大容量5のため、

アプリは「接続予約のタイムアウト」まで待機。

タイムアウトになると例外発生




接続要求時に未使用接続が無い場合②


接続プールの縮小

• WebLogicが起動し、接続プールが初期化された後、「縮小頻度」で設定した時間が経過したとき、接続プールが「初期容量」以上に増加していた場合、接続プール中の未使用の接続数は、「最小容量」値まで自動的に縮小される。その後も、「縮小頻度」の間隔で縮小処理が行われる。

• 使用中の接続は縮小対象にはならないが、それにより「最小容量」まで縮小できない場合は使用後に即縮小される。（縮小間隔もリセットされる。）

• 「初期容量」＝「最大容量」の場合は、当然ながら縮小されない。

• 縮小処理は、管理コンソールから手動で行うことも可能。

接続プール



データソース初期化後

「縮小頻度」 900秒の間隔で

「最小容量」 3まで縮小

初期化縮小縮小

縮小頻度縮小頻度


データベース再起動時

• 今回の前提のように「予約時にテスト」=Falseかつ「テスト頻度」=0が設定されているデータソースで、接続プールに正常に接続が作成された後、データベースが再起動した場合、接続プール中の全接続は無効となり、アプリケーションが接続要求を行うと下記例外が発生する（Oracle Database10gの場合）

• java.sql.SQLRecoverableException: ソケットから読み込むデータはこれ以上ありません。

• この場合、次のスライドの対処を行わない限りアプリケーションはデータソースを利用できない。

接続プール



停止起動

②DB再起動

①接続プールに

正常に接続を作成


③ getConnection()

で予約

④ 使用時に

例外発生


データベース再起動時の対処方法 • 今回の前提のように「予約時にテスト」=Falseかつ「テスト頻度」=0が設定されているデータソースで、接続プールに正常に接続が作成された後、データベースが再起動した場合、接続プール中の全接続は無効となり、アプリケーションはデータソースを利用できなくなる。

• この場合は、管理コンソールを利用し、データソースの「停止」、「起動」またはデータソースの「リセット」を行い、接続プールに有効な接続を再作成することで、再度アプリケーションから利用可能となる。

接続プール

データソース test ③データソースを

「停止（強制停止）」->「起動」

または「リセット」

することでアプリから

再度利用可能になる


停止起動

②DB再起動




データベース再起動時の問題の予防策①

• データソースの接続プールに接続が作成された後にデータベースが再起動した場合の問題は、下記パラメータを設定することで予防することができる。

• 「予約時にテスト」をTrueにし、「テスト対象の表名」に有効なSQLまたは表名を設定する。

• 「予約時にテスト」をTrueにすると、アプリケーションが接続要求時に、接続プールの接続が有効か実際にSQLを発行してテストを行う。もしSQLが成功しない場合はその接続を破棄し、新たに接続を作成する。（アプリケーションでは例外が発生せず、正常に接続を取得できる。）

• ただし、接続要求都度にSQLを発行するため、理論上、DB側の負荷が幾ばくか高まる

接続プール



停止起動

②DB再起動




③ getConnection()

で予約

⑤正常に接続を

利用可能 ④「テスト対象の表名」

で指定したSQLを発行し

接続の有効性をテスト。

無効接続の場合、

その接続を破棄、

再作成する。

「予約時にテスト」＝trueの場合


データベース再起動時問題の予防策②（推奨）

• データベース再起動時には、データソースの接続プールに無効接続が発生するが、無効接続が長期間接続プールに滞留すると、JDBCサブシステム自体が不安定になり WebLogicプロセスが「Failed」ステータスに移行する可能性が高い。そのため、データベース再起動時の問題の予防策としては、「予約時のテスト」 = True のみならず、「テスト頻度」を0以外の値を設定することを推奨する。

• 例えば「テスト頻度」を60に設定すると、接続プールの未使用接続を60秒単位でテストを行い、無効であれば破棄、再作成を行う。

接続プール



停止起動

②DB再起動




③ getConnection()

で予約

⑤正常に接続を

利用可能 ④「テスト対象の表名」

で指定したSQLを発行し接続の有効性をテスト。

無効接続の場合、その接続

を破棄、再作成する。未使用接続も「テスト頻度」

で指定した間隔でテスト、無効接続の場合、その接続

を破棄、再作成する。

「予約時にテスト」＝trueの場合


JDBCデータソースの作成①

32

• 管理コンソールにログインして下図の操作を行います。

②「ドメイン構造」で

「サービス」-「データソース」を選択



③「JDBCデータソースのサマリ」で「新規」－「汎用データ・ソース」ボタンを選択


JDBCデータソースの作成②

33

• データソース名やJNDI名などを指定します。 ①「名前」で「test」を入力

②「JNDI名」で「jdbc/test」を入力

③「データベースの種類」で「Oracle」を選択して「次へ」ボタンを選択


JDBCデータソースの作成③

34

• データベース・ドライバの選択

①「データベース・ドライバ」で「Oracle Driver (Thin) for Service Connections」を選択して

「次へ」ボタンを選択


JDBCデータソースの作成④

35

• デフォルトのまま、「次へ」ボタンを選択します。


JDBCデータソースの作成⑤

36

• データベースの接続プロパティを設定

以下の内容を入力します。

データベース名：XE

ホスト名：localhost

ポート：1521（デフォルト）

データベースユーザ名：HR

パスワード：hr

パスワードの確認：hr


JDBCデータソースの作成⑥

37

• 「構成のテスト」ボタンを選択し、接続テストが正常処理されることを確認したら「次へ」ボタンを選択します。


JDBCデータソースの作成⑦

38

• 「サーバ」で「Server1」を選択して「終了」ボタンを選択します。


JDBCデータソースの作成⑦

39

• 「変更のアクティブ化」ボタンを選択して構成内容を確定させます。

ボタン選択後、「すべての変更がアクティブ化されました。再起動は不要です。」

のメッセージが表示されることを確認


接続プールの設定①

40

• 作成したデータソース「test」リンクを選択します。


接続プールの設定②

41

• 「接続プール」タブ画面を表示します。

②「接続プール」タブを選択




接続プールの設定③

42

• 「初期容量」と「最大容量」に10を設定して保存ボタンを選択します。


接続プールの設定④

43

• 「変更のアクティブ化」ボタンを選択して構成内容を確定させます。

ボタン選択後、「すべての変更がアクティブ化されました。再起動は不要です。」

のメッセージが表示されることを確認


接続プールの監視設定①

44

• 作成したデータソース「test」の「監視」画面を表示します。

①「モニタ」タブを選択

③「この表のカスタマイズ」リンクを選択

②「統計」タブを選択


接続プールの監視設定②

45

• 監視したい項目を選択します。

①「現在アクティブな接続数」、

「アクティブな接続の最大数」、

「接続遅延時間」、

「最大使用可能数」

を追加

②「適用」ボタンを選択


接続プールの監視設定③

46

• 「最大使用可能数」が10であることを確認します。


[参考] データソース作成後の接続テスト

47

データソースを作成後に、そのデータソースの接続テストを行うには下記の設定が必要です。

1. 「チェンジセンタ」で「ロックして編集」ボタンを選択 2. 「ドメイン構造」で「サービス」-「JDBC」-「データソース」を選択

3. 「JDBCデータソースの概要」で、テストするデータソースの名前リンクを選択

4. 「接続プール」タブを選択し、画面下部の「詳細」リンクを選択

5. 「予約時に接続テスト」にチェックをいれる

6. 「テスト対象のテーブル名」に適切なテーブル名またはSQL文が指定されていることを確認

7. 「保存」ボタンを選択後、「変更のアクティブ化」ボタンを選択

8. 「モニタ」タブ、「テスト」タブで「サーバ」を指定して「データソースのテスト」ボタンを選択、

接続テストが実施され、メッセージが表示されることを確認


7: アプリケーションのデプロイ、起動および停止


Webアプリケーションの開発とデプロイ

• 下図のようなDBにアクセスするエンタープライズアプリケーション(earファイル)をWebLogic Server 12cにデプロイします。

• 検索文字列を入力し、ボタンを押下すると、EMP表（従業員表）から名前に部分一致するものを表示します

49

検索の実行結果例


WebLogic Serverのアプリケーション・アセンブル形式

• アプリケーション・アセンブル形式

• 一般的には特定のディレクトリ構造をZIP形式にアセンブルする。

• Webアプリケーションは、xxxx.war

• EJBアプリケーションは、xxxx.jar

• エンタープライズ・アプリケーションは、xxxx.ear

• WebLogicでは、ディレクトリを展開した形式でデプロイすることも可能

50

WARファイル

エンタープライズ・アプリケーション

JARファイル

Webアプリケーション EJBアプリケーション

WARファイル JARファイル

EARファイル Webアプリケーション EJBアプリケーション


[参考] アプリケーションのディレクトリ構造

• Java EEのアプリケーションは、下記のようなディレクトリ構造でまとめます。

51

WARファイル

classes

lib

WEB-INF

JSPファイル

HTMLファイルやgiｆ、jpgファイル等

サーブレットのクラスファイル

使用するライブラリ(JARやZIP)

配布記述子（web.xml)

＜ルート＞

EARファイル

META-INF

EJBがまとめられたJARファイル

配布記述子（application.xml)

＜ルート＞

WARファイル

リソースファイル

J2EEクライアントモジュール etc..


管理コンソールからのデプロイ①

52

• AdminServerとServer1が起動状態であることを確認します。

• WebLogic Server管理コンソールにログインし、「チェンジ・センタ」で「ロックして編集」ボタンを選択します。


管理コンソールからのデプロイ②

53

• 「ドメイン構造」- 「デプロイメント」を選択します。

• 画面右側の「デプロイメントのサマリ」で、「インストール」ボタンを選択します。


C:¥HandsOnFiles¥Emp.ear

管理コンソールからのデプロイ③

54

• アプリケーションのファイルを指定します。

• 「C:¥HandsOnFiles¥Emp.ear」を指定して「次へ」ボタンを選択してください。


管理コンソールからのデプロイ④

55

• そのまま「次へ」ボタンを選択してください。


管理コンソールからのデプロイ⑤

56

• アプリケーションの配布先のサーバを指定します。

• 「Server1」のみチェックして「次へ」ボタンを選択します。


管理コンソールからのデプロイ⑥

57

• アプリケーションの名前が、「Emp」であることを確認して「終了」ボタンを選択します。


管理コンソールからのデプロイ⑦

58

• 「チェンジ・センタ」で「変更のアクティブ化」ボタンを選択してデプロイ操作を確定させます。


管理コンソールからのアプリケーション起動①

59

• 「すべての変更がアクティブ化されました。再起動は不要です。」のメッセージを確認した後、「Emp」の左横のチェックBOXにチェックをして、「起動」-「すべての要求を処理」を選択します。


管理コンソールからのアプリケーション起動②

60

• 「はい」ボタンを選択します。


管理コンソールからのアプリケーション起動③

61

• デプロイメント表で「Emp」の「状態」が「アクティブ」になったことを確認します。


アプリケーションの実行

62

• Webブラウザを起動し、http://localhost:7002/ EmpWeb を指定します。

• 入力エリアに「A」を入力して「Search」ボタンを押下し、アプリが正常に実行されることを確認します。

検索結果例


管理コンソールからのアプリケーション停止

63

• 「デプロイメント」表で停止するアプリケーションをチェックして「停止」ボタン- 「直ちに強制停止」を選択します。確認要求画面で、「はい」を選択します。


管理コンソールからのアンデプロイ

64

• 「チェンジセンタ」で「ロックして編集」ボタンを選択します。

• 「ドメイン構造」から「デプロイメント」を選択して、「デプロイメント」表でアンデプロイするアプリケーションの状態が「準備完了」であることを確認します。その後、Emp.earの行のチェックボックスをチェックし、「削除」ボタンを選択します。確認要求画面で、「はい」を選択します。

• 「チェンジセンタ」で「変更のアクティブ化」ボタンを選択してアンデプロイを確定させます。


Oracle WebLogic Server Quiz


WebLogic Server Quiz

66

Questions Answers

Q1

Q2

Q3

Q4

Q5

Q6

Q7

Q8





WebLogic Server活用術 2013年8月7日



アジェンダ

Java EE 6

WebLogic Server 12.1.2 – WebSocket

クラスタリング

WebLogic Serverのトランザクション

WebLogic Scripting Tool(WLST)とMBean

Active GridLink for RAC


Java EE 6


Java EE 6進化の経緯初期のJava EE（J2EE）の誕生した背景

– クライアント・サーバ型システムが主流

– Multi Tierを前提とした設計思想を元にJ2EEが誕生

J2EEの問題点

– 冗長・複雑な設計・コード記述の作法、大量の設定ファイル

– J2EEコンテナへの依存によるテストの困難さ

Java EE 6はLightweightなアプリケーション環境を提供さらに柔軟な開発が可能な仕様を追加

より簡易なオープンソース・フレームワークを利用した開発が増加

Java EE 5 から Ease of Development をテーマに仕様改善優良なオープンソース・フレームワークを標準仕様化


Java EE 6による先進的な開発環境

• 開発APIの簡素化 • 標準ベースの依存性注入（DI:Dependency Injection）

• Light weightな標準仕様からHigh volume

な標準仕様まで網羅的にサポート

柔軟性・軽量化

• 生産性の高いオープンソース・フレーム

ワークの取り込み

• JSF/Ajaxの採用によるリッチなWeb

アプリケーション環境の実現 • 標準ベースの採用によるロックインからの脱却

拡張性

• POJOプログラミング・モデルの採用

• IDEサポートの容易なアノテーションの活用

• 煩雑なXML設定ファイルの削減

• アノテーションによるディスクリプタの削減

開発生産性


Java EE 6 仕様の全体像

WebコンテナへのEJBのデプロイが可能（EJB Lite）

– WebアプリケーションからEJBをローカル呼出し

– WebコンテナのみでEJBを利用したアプリケーションを実行可能

Lightweight なWebアプリケーション環境を提供

EJB コンテナ Web コンテナ

CD

I & D

I

Bean

V

alid

atio

n

JSF

JST

L

JPA

JMS

JTA

JCA

JavaM

ail

JAC

C

JAS

PIC

WS

M

eta

data

JA

X-R

S

JAX

-RP

C

JAX

-WS

JAX

-B

SAAJ

Web EJB Lite

Java SE

CD

I & D

I

Bean

V

alid

atio

n

JPA

JMS

JTA

JCA

JavaM

ail

JAC

C

JAS

PIC

WS

M

eta

data

JA

X-R

S

JAX

-RP

C

JAX

-WS

JAX

-B

SAAJ

EJB

Java SE

RMI/IIOP

JDBC JDBC


Java EE 6 における代表的な標準仕様開発生産性・拡張性・柔軟性の向上

標準仕様開発領域特徴

JSF 2.1

ユーザインタフェース

• リッチなユーザインタフェースの効率的な開発を実現

Servlet 3.0

• 冗長な設定・コード記述の削減により開発生産性を向上

• 非同期ServletによるAjax対応

EJB 3.1 ビジネスロジック

• 冗長な設定・コード記述の削減により開発生産性を向上

• より柔軟な制御機能の追加

JAX-RS サービス公開 • 容易なサービス公開を実現するWebサービス標準仕様

CDI 全領域 • レイヤ間の疎結合化による柔軟性を向上するDIフレームワーク標準仕様

最新のWebアプリケーションを効率良く開発


Context and Dependency Injection(CDI)

CDIとは Java EE 6の仕様の一つ

– Contexts：サーバ上の状態を表現するもの

– Dependency Injection：依存性の注入

概要

コンポネント間を疎結合にできるコードがよりシンプルになる

インスタンスのライフサイクル管理や

インスタンス(の依存関係)の注入をコンテナが引き受ける

（＝プログラマが、クラスをnewしたり、setメソッドを呼び出す必要が減少）


Context and Dependency Injection(CDI) 何ができるか

DI(依存性注入) インターセプト

インスタンスのライフサイクル管理 EL式からのアクセス

Bean

Bean HTTPリクエスト



CDIはJava EE 6に準拠したアプリケーションサーバで使用可能

– Oracle WebLogic Server 12c

アプリケーションでCDIを有効にするには、beans.xmlが必要

– WARファイルの場合

「WEB-INF/beans.xml」を配置

– beans.xmlは中身が空でもよい

(特に記述する必要がない場合)

CDIを使うには



DIの機能はJava EE 5 でも使用可能だが…

Java EE 5のDI

@ManagedBean public class SampleMg { @EJB private Logic lg; }

JSF EJB JPA 依存関係

@Stateful public class Logic { @PersistenceContext(unitName=“JPA”) private EntityManager em; }

<?xml version="1.0" encoding="UTF-8" ?> <persistence xxx> <persistence-unit name=“JPA"> …略

プレゼンテーション層ビジネスロジック層データアクセス層

依存関係

注入する種別によってアノテーションが異なる注入先も限定的



CDIを使用したコーディング

Java EE 6のCDI

@Named @RequestScoped public class SampleMg { @Inject private Logic lg; }

JSF EJB JPA 依存関係

@Stateful public class Logic { @Inject private EntityManager em; }

<?xml version="1.0" encoding="UTF-8" ?> <persistence xxx> <persistence-unit name=“JPA"> …略

プレゼンテーション層ビジネスロジック層データアクセス層

依存関係

注入する種別が異なっても@Injectで注入可能注入先も自由



注入先の型がインターフェースの場合

実装クラスのインスタンスを生成して注入

実装クラスが複数ある場合はエラー

Java EE 6のCDI：何を注入するか①

public class xxBean{ @Inject private BizLogic logic; }

public class BizLogicImpl implement BizLogic { }


public class BizLogicImplJAPAN implement BizLogic { }

public class BizLogicImplUS implement BizLogic { }

Error

Qualifierの機能を使用して適切に注入できるようになる

public class xxBean{ @JPN @Inject private BizLogic logic; }

@JPN public class BizLogicImplJAPAN implement BizLogic { }

注入

注入

解決方法例



@Producesアノテーションを使用

– 動的に注入することも可能

Java EE 6のCDI：何を注入するか②


public class BizLogicImplJAPAN implement BizLogic { }

public class BizLogicImplUS implement BizLogic { }

public class HelloGenerator { @Produces public BizLogic createBizLogic{ // 条件毎に分岐 if( xxx ){ return new BizLogicImplJAPAN(); } else if( yyy ){return new BizLogicImplUS(); }

注入

注入

or


ビルトインのスコープ一覧


# 種別概要イメージ

1 @RequestScoped

1回のHTTPリクエストの期間

2 @ApplicationScoped

アプリケーションの生存期間と同じ

3 @SessionScoped

HTTPセッションの期間

4 @ConversationScoped

1回のHTTPリクエストの期間

もしくは、任意の期間

5 @Dependent （デフォルト）

バインドされたインスタンスに依存する

Beanのスコープ（１）

？

Webアプリ

ケーションと

同じ

HTTPリクエスト&レスポンス


Context and Dependency Injection(CDI) Beanのスコープ（２）ConversationScoped

package beans; import java.io.Serializable; import javax.enterprise.context.Conversation; import javax.enterprise.context.ConversationScoped; import javax.inject.Inject; import javax.inject.Named; @Named @ConversationScoped public class ConverBean implements Serializable{ @Inject private Conversation conversation; public void begin(){ conversation.begin(); } public void end(){ conversation.end(); } }

インスタンス生成

Conversation#begin()

インスタンス破棄

Conversation#end() Conversation#setTimeout()によるミリ秒で指定した時間の到来で破棄も可能


Context and Dependency Injection(CDI) Beanのスコープ（３） Dependent

バインド先のインスタンスのライフサイクルに合わせる

– 例えば、Servletの実装クラスにBeanを注入した場合

Beanのライフサイクルは、Servletのライフサイクルと同じとなる

xxxServ

let

xxxBean

xxxServ

let

@R

eq

uest

Sco

ped

xxxBean

@R

eq

uest

Sco

ped

xxxBean

@R

eq

uest

Sco

ped

xxxBean


Context and Dependency Injection(CDI) EL式からのアクセス

JSFパッケージのManagedBeanをCDIのBeanに置き換え可能

– EL式からアクセスするには、@Namedアノテーションが必要

– EL式ではデフォルトでクラス名でアクセス

クラス名：TestBean ⇒ EL：testBean

<body>

<h:outputText value="#{testBean.msg}" />

</body>

xxxx.xhtml @RequestScoped public class TestBean {

@Named @RequestScoped public class TestBean {


WebLogic Server 12.1.2

WebSocket


文章を記述するための仕様から

Webアプリケーションを記述するための仕様へ進化

CSS3 & Styling

HTML5

HTML要素, 構文, UI, etc

オフライン＆ストレージ

デバイスアクセス

接続性

マルチメディア

3D & Effects

Performance & integration

http://www.w3.org/html/logo/


全体像

主としてクライアント側に関する要素

– HTML5タグ, オフライン&ストレージ, デバイスアクセス, マルチメディア,

etc

クライアント-サーバーの通信に関する要素

– 接続性: WebSocket

Web

Socket

クライアント側サーバー側


クライアントサーバ

WebSocket

PUSH

HEADDER

Data

HEADDER

Data

• HTML5のための高速、高効率通信技術

• 双方向のPUSH配信


HTTPリクエスト

HTTPレスポンス


一般的なHTTP通信通信シーケンス GET / HTTP/1.1

Host: twitter.com

User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0)

Gecko/20100101 Firefox/16.0

Accept:

text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Accept-Language: ja,en-us;q=0.7,en;q=0.3

Accept-Encoding: gzip, deflate

Connection: keep-alive HTTP/1.1 200 OK

Cache-Control: no-cache, no-store, must-revalidate, pre-check=0,

post-check=0

Content-Encoding: deflate

Content-Type: text/html; charset=utf-8

Date: Thu, 08 Nov 2012 01:10:49 GMT

Etag: "6ea25bec4ea3713ea6202a9eb0c19f90"

Expires: Tue, 31 Mar 1981 05:00:00 GMT

Last-Modified: Thu, 08 Nov 2012 01:10:47 GMT

Pragma: no-cache

Server: tfe

Set-Cookie: dnt=; domain=.twitter.com; path=/; expires=Thu, 01-

Jan-1970 00:00:00 GMT

Status: 200 OK



WebSocket技術通信シーケンス: コネクション確立

GET /mychat HTTP/1.1

Host: server.example.com

Upgrade: websocket

Connection: Upgrade

Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==

Sec-WebSocket-Protocol: megachat, chat

Sec-WebSocket-Extensions : compress, mux

Sec-WebSocket-Version: 13

Origin: http://example.com

HTTP/1.1 101 Switching Protocols

Upgrade: websocket

Connection: Upgrade

Sec-WebSocket-Accept:

HSmrc0sMlYUkAGmm5OPpG2HaGWk=

Sec-WebSocket-Protocol: chat

Sec-WebSocket-Extensions: compress, mux



WebSocket技術データ通信

PUSH

HEADDER

Data

HEADDER

Data


サーバー負荷の低減

– ポーリングモデルからPUSH配信へ

– アプリケーションサーバー、データベースへの負荷を大幅低減

ネットワーク負荷低減

– ポーリングによる無駄な通信の排除＋データ部だけをPUSH配信

– ネットワークトラフィック量の大幅削減、ネットワーク帯域の節約

ユーザービリティの向上

– 特定技術（Flash等）や外部サービス（Google, Apple）に依存せず

リアルタイム配信を実現

WebSocketのメリット


WebLogic Server 12.1.2: WebSocket WebSocket + TopLink Data Service

Database WebLogic Server

TopLink

Data Service

JDBC

Client

REST JSON/XML

Change Notification

TopLink 12.1.2

WebSocket


クラスタリング


WebLogic Server基本クラスター・アーキテクチャ

クラスタの重要な機能

– 負荷分散 – クラスタメンバにリクエストを均等に分配

– フェイルオーバ – 障害発生時も処理を別のクラスタメンバで継続する

mydomain

cluster1

Server1

Web コンテナ

EJB コンテナ

Server2

Web コンテナ

EJB コンテナ

RDBMS プロキシ

データソース

データソース

HTTPリクエストを負荷分散


WebLogic Serverクラスタの設定クラスタの設定: WebLogicドメインで設定

プロキシの設定: プロキシ側で設定

mydomain

cluster1

Server1

Web コンテナ

EJB コンテナ

Server2

Web コンテナ

EJB コンテナ

RDBMS プロキシ

データソース

データソース

AdminServer ドメイン設定

設定ファイル

HTTPサーバやロードバランサの設定

Weblogic Serverドメインの設定


HttpSessionインメモリレプリケーションプロキシプラグインの動作

– リクエストをWebLogic Serverにプロキシする

– リクエストのURLまたはMIMEタイプ、もしくはその両方でプロキシ可能

– セッションを持つHTTPリクエストはセッションを格納しているサーバにルーティングする

– クラスタ内の障害発生サーバにはプロキシしない

HttpSession をクラスタ内の2つのサーバで保持

– セッション毎にプライマリ・セカンダリサーバが決定される

– サーバにはプライマリ・セカンダリセッションが混在する

メモリ消費量が増大する

cluster1

プロキシ

Server1 Server2 Server3

セカンダリ

1

クライアント

プライマリ

1

2 2

3

3


HttpSessionインメモリレプリケーション

プライマリ = Server3

セカンダリ = Server2

プライマリサーバは負荷分散によって初回リクエスト時に決定

– セカンダリサーバはレプリケーション・グループとマシン設定からHttpSession生成時に決定

– セカンダリサーバへの同期はHttpSession#setAttribute()がトリガになる

– プライマリ・セカンダリサーバ情報はCookieに埋め込まれる

cluster1

プロキシ


セカンダリ

setAttribute()

クライアント

プライマリ



プライマリサーバに障害が発生するとセカンダリが昇格

– 別のサーバでセカンダリが再生成される

プロキシプラグインによってセカンダリサーバにリクエストの振り替えられる

– 振り替えはクライアントからの次のリクエスト時

– プロキシプラグインはCookieのサーバリストをもとにセカンダリサーバに接続



cluster1

プロキシ

クライアント


プライマリプライマリセカンダリ



プライマリに昇格したサーバはCookieを更新

– プライマリとセカンダリ情報が更新されたCookieがクライアントに戻される

cluster1

プロキシ

Server1 Server3

セカンダリ



Server2

setAttribute()

プライマリ

クライアント


インメモリレプリケーションの考慮事項

リクエストのフェイルオーバはプラグインによって行われる

– クライアントからのリクエスト到達までにプライマリ/セカンダリサーバが共にダウンするとセッションは継続できない

– セッションの消失が許容できない場合はインメモリレプリケーションは選択不可

– IMRを使用する場合は3つ以上のサーバでクラスタを構成することを推奨

HttpSessionに格納するデータサイズが大きすぎるとレプリケーションでオーバーヘッドが発生する

– HttpSessionに格納するデータは可能な限りコンパクトに

java.io.Serializableの実装も忘れずに

– 同期のトリガはHttpSession#setAttribute()


WebLogic Serverの

トランザクション



WebLogic Server

JNDI

トランザクションマネージャ

セキュリティ・レルム

LDAP ATN Audit

or ATZ

JMSサーバ Destination

(Queue /Topic)

JDB

C

データソース

RDBMS

Web サーバ

Plug

In Web Container

EJB Container

Java EE アプリケーショ

ン

JMS

RMI

JTA

JDBC JAAS

JNDI

Servlet

JSP EJB JPA JSF


X/Open DTPモデル

Application Program (AP)

Transaction Manager

(TM)

Resource Manager (RM) Resource Manager

(RM) Resource Manager (RM)

XA

APはトランザクション境界を指定

APはRMを介してリソースを使用

TMとRMのインタフェース


Java EEにおけるトランザクション仕様

JTA(Java Transaction API)

– X/Open DTPモデルをベースにした分散トランザクションAPIトランザクションマネージャとトランザクション参加者であるアプリケーション、リソースマネージャが使用する標準インタフェースを提供

javax.transaction.TransactionManager - トランザクションマネージャが使用

javax.transaction.UserTransaction – ユーザが使用

javax.transaction.xa.* - トランザクションマネージャ(TM)とリソースマネージャ(RM)間の規約

JTS (Java Transaction Service)

– JTAをサポートするトランザクションマネージャ実装を提供OMG Object

Transaction Service(OTS) 1.1 仕様に対応したJava実装のサービス


WebLogic Serverのトランザクション設定

トランザクションサービスはWebLogic Server起動時に開始される

トランザクションの設定

– ドメイン・レベルで設定を行う

– ドメインで同じトランザクション設定を使用

トランザクションのモニタリング

– サーバ・レベルでモニタリングを行う

– 管理コンソール, WLST …

参加リソース(JDBCデータソースなど)の設定

– リソース・レベルで設定を行う

トランザクションサービス


トランザクションのモニタリングサーバ・レベルで監視


TRS(トランザクション回復サービス)

WebLogic ServerのTMではトランザクション回復サービスを提供

– サーバ起動時に自動的に実行

– TLogを解析して未完了のトランザクションの解決を行う

– 2PC処理を完了させる(フェーズ1, フェーズ2)

– ヒューリスティックな終了をログに記録

サーバに障害が発生した場合の対応

– TLogにアクセスできる状態でサーバを起動する

– ハードウェア障害に対応するにはTLogの複製が必須

– 高性能Disk or JDBCストア

– クラスタ構成の場合はサービス移行orサーバ移行可能


JDBC TLOGとは

従来はファイルストア(デフォルト・ストア)のみに格納できたトランザクション・ログ(TLOG)を、より信頼性かつ利便性の高いデータベースへ格納できるようにした機能


Logging Last Resource(LLR)

XA Data

Source

Non-XA Data

Source

JMS XA

Connection

1 WebLogic

Server

(TM)

Application

Commit

2

2 2PC:prepare

3

4

5

5

2PC:commit

非XAリソースコミット

(ローカルTX)

コミットレコード

挿入

LLR Table


「ヒューリスティック」について語ろう！ 2PC処理中にRMによる一方的な決定(commit/rollback)が行われた状態

– インダウト中のTM障害や、トランザクション破棄、トランザクションの手動解決などにより発生

– ヒューリスティックな終了の状態によってスローされる例外が異なる

ヒューリスティックな決定説明

HeuristicRollback RMがRollbackしてしまった。TMが他のTXブランチをコミットすると不整合発生

HeuristicCommit RMがCommitしてしまった。TMが他のTXブランチをRollbackすると不整合発生

HeuristicMixed 複数のリソースでHeuristicRollbackとHeuristicCommitが発生していることをTMが認識している状態

HeuristicHazard HeuristicMixedが発生しているが、TMがRMのステータスを識別できていない状態


WebLogic Scripting Tool

(WLST)とMBean


WebLogic Scripting Tool(WLST)とは WLSTはWebLogic ドメインの作成、管理、監視に使用できる

– 構成情報、監視情報をあらわすMBeanを直接操作可能

– 構成情報: ConfigurationMBean / EditMBean

– 監視情報: RuntimeMBean

Jythonベースのツール

用途に応じた起動モード

– 対話モード/スクリプトモード/組み込みモード

WLSTではMBeanをダイレクトに操作するのでMBeanの理解を深める必要があります


WLSTの実行方法

対話モード

> java weblogic.WLST

スクリプトモード ( -i : スクリプト終了後に対話モード)

> java weblogic.WLST xxx.py

> java weblogic.WLST –i xxx.py

対話モードで > execfile('xxx.py') でもスクリプト実行可能

組み込みモード

– weblogic.management.scritping.utils.WLSTInterpreter を使用

exec('command_str')メソッドで実行

TIPS: WLST実行前にCLASSPATHを設定 ⇒$WL_HOME/server/bin/setWLSEnv.sh (cmd)


WLSTの機能

複数のツールで実行していたWebLogic Serverの管理作業をWLSTひとつに集約できる

ドメイン構成ウィザード

weblogic.Deployer

Administration Console

WLST


JMX MBeanとは

JMX (Java Management Extensions)

– Java環境の管理・監視のための標準仕様

– JCPのJSR-003(JMX ) と JSR-160(JMX Remote)で策定されている。

MBean (Managed Bean)

– JMX仕様の中で定義されている管理/監視用のJavaコンポーネント

– MBean Server経由で管理対象の状態を取得したり、操作や通知を行うインターフェースをもつ


JMX MBeanのアーキテクチャ

MBean

MBean

MBean

管理対象

管理対象

管理対象

Connector

Protocol

Adapter

MBean Server

Agent Level Instrumentation Level Distributed Services Level

JMX-compliant

Management

Application

Web

Browser

HTTP

Instrumentation Level 管理対象にアクセスするためのMBeanを指すレイア

Agent Level MBeanのコンテナとなるMBean Serverを指すレイア。MBeanは、MBean Serverへ登録することで利用可能になる。

Distributed Services Level Connectorや Protocol Adapterを通じてMBean Serverと通信するためのインターフェースを指すレイア


WebLogic ServerのMBeanサーバ

MBeanサーバ種類概要 MBeanサーバの

ホストになるもの

Domain Runtime

MBeanサーバ

ドメイン全体のサービス用の MBean。この MBean サーバは、管理対象サーバ上にある MBean への単一のアクセスポイントとしても機能する。

WebLogicの

管理サーバ

Runtime

MBeanサーバ

特定の WebLogic Server インスタンスのモニタ、実行時制御、およびアクティブなコンフィグレーションを表すMBeanを提供する MBeanサーバ。

WebLogicドメイン中の管理サーバと


Edit

MBeanサーバ

保留中のコンフィグレーション MBean と、WebLogic Server

ドメインのコンフィグレーションを制御するMBeanを提供する。変更のロック、保存、およびアクティブ化用の

ConfigurationManagerMBean をエクスポーズする。

ドメインのコンフィグレーションを変更するには、この MBean

サーバを使用する。

WebLogicの

管理サーバ

JVMのプラットフォームMBeanサーバ

JVMから提供されJVM 自体のモニタ情報を保持する MBean

サーバ。このMBeanサーバからWebLogicのRuntime MBean

サーバを利用することも可能

JVM


WLSTのユースケースを語ろう！（デプロイ例）

準備完了

アクティブ

①

② ③

④

⑥ ⑤

⑦

デプロイなし

管理

③ ②

② ③

WLST weblogic.Deployer

① distributeApplication() -distribute

② startApplication() -start

③ stopApplication() -stop

④ undeploy() -undeploy

⑤ deploy() -deploy

⑥ undeploy() -undeploy

⑦ redeploy() -redeploy


Active GridLink for RAC


Active GridLink for RACのポイント

1. Universal Connection Pool(UCP)との統合

2. Single Client Access Name(SCAN)に完全対応

3. RACからの通知による高速接続フェールオーバ

(Fast Connection Failover; FCF)

4. RACの負荷状況を考慮した実行時接続ロードバランシング

(Runtime Connection Load Balancing; RCLB)

5. XAトランザクションのRACインスタンス・アフィニティ

6. WebセッションのRACインスタンス・アフィニティ(WLS12.1.1～)


Active GridLink for RACの仕組み

WebLogicデータソースと統合されたUCP(Universal Connection Pool)が、ONS(Oracle Notification Service)から通知されるRAC側の構成変更/負荷状況のイベントを元に、適切な接続の制御(ロードバランシング、フェールオーバ、アフィニティ)をおこなう

O

NS clie

nt

UCP-RAC

モジュール

ONS Daemon

ONS Daemon

WebLogic Server Oracle Database（RAC）

死活・負荷状況通知

GridLinkデータソース

（サービスA用）

インスタンス1

インスタンス2

サービス

A


実行時接続ロードバランシング(RCLB)

WebLogic

Connection Pool

Application

I’m busy

I’m very busy

I’m idle

30% connections

10% connections

60% connections

RAC Database

Instance1

Instance2

Instance3


XAアフィニティ

WebLogic Server

RAC Database

Instance1

Instance2

Instance3

EJB1

WebLogic Server

EJB

EJB3

EJB2

EJB4 Transaction

Affinity Context


Web セッション・アフィニティ

RAC Database

Instance1

Instance2

Instance3

WebLogic Server

Servlet

JSP

Servlet

JSP

JSP

HttpSession

Affinity Context


WebLogic Server 12.1.2のDB関連新機能

Application Continuity

– WebLogic ServerがOracle JDBC Driver12cのApplication Continuityを使用して、データベースに障害が発生しても、トランザクション処理を透過的に残存ノードに対して再実行する機能。

Database Resident Connection Pool(DRCP)サポート

– Oracle DatabaseのDRCPを活用することにより、WebLogic ServerとOracle

Database双方でDB接続・切断にかかるオーバーヘッドを削減しつつ、接続リソースの効率アップ。

Documents

WebLogic Server å 7 G - Oracle...2013/08/07 · 18:35 -19:25 N WebLogic Server - f ® Q þ 5O WebLogic Server - V ¥ k z4 H T c4 i ¥ - ÿ = & ³ ô - ô K Q B q » 1 * 9 å = WebLogic