Oracle WebLogic Serverについて

12cリリース1 (12.1.1)

B65923-02(原本部品番号:E24446-02)

目次

タイトルおよび著作権情報

はじめに

- ドキュメントのアクセシビリティについて

- 表記規則

1 はじめに

- 製品の概要

- プログラミング・モデル

- 高可用性

- 診断フレームワーク

- セキュリティ

- クライアント・オプション

- Oracle WebLogic Suiteとの統合

- 他のシステムとの統合

- Webサーバーとの統合

- WebLogic Server APIのサンプルとサンプル・アプリケーション

- アップグレード

2 システム管理

- WebLogic Serverシステム管理の概要

- 管理タスクに応じた適切な技術の選択

- システム管理ツールおよびAPIの概要

- WebLogic Serverシステムの管理のためのロードマップ

3 管理コンソールの概要

- 管理コンソールについて

- 管理コンソール・オンライン・ヘルプ

- コンソール・エラー

- 管理コンソールの起動

- 管理コンソールの有効化

- 管理コンソールの要素

- チェンジ・センター

- ドメイン構造

- 操作ガイド

- ツール・バー

- ブレッドクラム・ナビゲーション

- システム状態

- チェンジ・センターの使用

- 変更の取消し

- 構成ロックの解放

- 変更管理の機能について

- 動的な変更と動的でない変更

- 変更の表示

4 WebLogic Serverドメイン

- ドメインについて

- ドメインの整理

- ドメインの内容

- 管理サーバー

- 管理対象サーバーと管理対象サーバー・クラスタ

- リソースとサービス

- WebLogic Serverドメインの理解のためのロードマップ

5 WebLogic Serverクラスタリング

- WebLogic Serverクラスタの概要

- クラスタとドメイン間の関係

- クラスタリングの利点

- クラスタの重要な機能

- クラスタリング可能なオブジェクトの種類

- クラスタリング不可能なオブジェクトの種類

- WebLogic Serverでのクラスタリングのためのロードマップ

6 WebLogic Serverでのアプリケーション開発

- WebLogic ServerとJava EEプラットフォーム

- Java EEアプリケーションとモジュールの概要

- WebLogic Serverでのアプリケーション開発のためのロードマップ

7 WebLogic Serverでのアプリケーションのデプロイ

- デプロイメント・プロセスの概要

- Java EE 6デプロイメントの実装

- 迅速なデプロイメントのガイド

- Java EEデプロイメント

- 自動デプロイメント

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

- システム管理者用ツール

- JSP/HTMLデプロイメント

- WebLogic Serverでのアプリケーションのデプロイのためのロードマップ

8 WebLogic Serverデータ・ソース

- JDBCデータ・ソースについて

- 汎用データ・ソースについて

- GridLinkデータ・ソースについて

- JDBCマルチ・データ・ソースについて

- WebLogic Serverデータ・ソースのためのロードマップ

9 WebLogic Serverメッセージング

- JMSとWebLogic Serverの概要

- Java Message Service

- WebLogic JMSのアーキテクチャと環境

- WebLogic Serverメッセージングのためのロードマップ

10 WebLogic Serverセキュリティについて

- WebLogic ServerでサポートされているJava EE 6のセキュリティ機能

- WebLogic Serverセキュリティ・サービスの概要

- WebLogic Serverセキュリティ・サービスのアーキテクチャ

- WebLogicセキュリティ・フレームワーク

- WebLogicセキュリティ・フレームワークによるシングル・サインオン

- WebLogic WebサービスでのSAMLトークン・プロファイルのサポート

- セキュリティ・サービス・プロバイダ・インタフェース(SSPI)

- WebLogicセキュリティ・プロバイダ

- WebLogic Serverセキュリティの管理

- セキュリティ・レルム

- セキュリティ・ポリシー

- OPSS (Oracle Platform Security Services)

- WebLogic Serverの保護のためのロードマップ

11 WebLogic Server Webサービス

- Webサービスの概要

- Webサービスの構造

- Webサービスの標準

- Webサービスのためのロードマップ

12 Enterprise JavaBeans (EJB)

- EJBについて

- WebLogic ServerでのEJBドキュメント

- その他のEJB情報

- セッションEJBによるビジネス・ロジックの実装

- ステートフル・セッションBean

- ステートレス・セッションBean

- シングルトン・セッションBean

- メッセージドリブンBeanによる疎結合ビジネス・ロジックの実装

- EJBの構造と環境

- EJBのコンポーネント

- EJBコンテナ

- 組込み可能なEJBコンテナ

- EJBメタデータ・アノテーション

- オプションのEJBデプロイメント記述子

- EJBのクライアントと通信

- EJBへのアクセス

- EJBの通信

- EJBのセキュリティ

- WebLogic ServerでのEJBのためのロードマップ

13 監視、診断およびトラブルシューティング

- WebLogic Server診断フレームワーク

- ロギング・サービス

- SNMPサポート

- カスタムJMXアプリケーション

- Java EE管理API

- WebLogic Serverにおける監視、診断およびトラブルシューティングのためのロードマップ

14 サンプル・アプリケーションおよびサンプル・コード

- Java EE 6のサンプル

- 追加のAPIサンプル

- Avitek Medical Records

- Derbyオープンソース・データベース

15 WebLogic Serverの互換性

- Java EE 6の互換性

- 生成されるクラスの互換性

- ドメイン内での互換性

- 永続的データの互換性

- APIの互換性

- プロトコルの互換性

Oracle® Fusion Middleware

Oracle WebLogic Serverについて

12cリリース1 (12.1.1)

B65923-02(原本部品番号:E24446-02)

2012年1月

このドキュメントでは、Oracle WebLogic Server機能の概要と、その機能を利用して企業向けソリューションを作成する方法について説明します。

Oracle Fusion Middleware Oracle WebLogic Serverの理解, 12c リリース1 (12.1.1)

B65923-02

Copyright © 2012 Oracle and/or its affiliates.All rights reserved.

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、Oracleまでご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007).Oracle America, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

はじめに

ここでは、このガイド『Oracle WebLogic Serverの理解』で使用されるアクセシビリティ機能および表記規則について説明します。

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docaccを参照してください。

Oracleサポートへのアクセス

Oracleのお客様は、My Oracle Supportから電子サポートにアクセスできます。詳細情報はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoか、聴覚に障害のあるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。

表記規則

このマニュアルでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

斜体

イタリックは、ユーザーが特定の値を指定するプレースホルダー変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

1 概要

この章では、Oracle WebLogic Server機能の概要と、その機能を利用して企業向けソリューションを作成する方法について説明します。この章の内容は以下のとおりです。

- 製品の概要

- プログラミング・モデル

- 高可用性

- 診断フレームワーク

- セキュリティ

- クライアント・オプション

- Oracle WebLogic Suiteとの統合

- 他のシステムとの統合

- Webサーバーとの統合

- WebLogic Server APIのサンプルとサンプル・アプリケーション

- アップグレード

製品の概要

Oracle WebLogic Serverは、スケーラブルな、エンタープライズ対応のJava Platform, Enterprise Edition (Java EE)アプリケーション・サーバーです。WebLogic Serverのインフラストラクチャでは、様々な種類の分散アプリケーションのデプロイメントがサポートされています。サービス指向アーキテクチャ(SOA)に基づいてアプリケーションを構築するには理想的な基盤です。SOAとは、アプリケーション・サービスの再利用を最大限にすることを目的とした設計手法のことです。http://www.oracle.com/technology/tech/soa/index.htmlを参照してください。

WebLogic ServerにはJava EE 6.0仕様が完全に実装され、標準のAPI群が用意されています。標準のAPIを使用すると、データベース、メッセージング・サービス、外部エンタープライズ・システムへの接続などの幅広いサービスにアクセス可能な分散Javaアプリケーションを作成できます。エンドユーザー・クライアントは、Webブラウザ・クライアントまたはJavaクライアントを使用してこうしたアプリケーションにアクセスします。また、Java EEモデルに対する代替手段を提供するJavaアプリケーションのプログラミング・モデルである、Spring Frameworkもサポートします。「プログラミング・モデル」を参照してください。

Java EEを実装してWebLogic Serverを使用すると、企業のミッション・クリティカルなアプリケーションを堅牢かつセキュアで、可用性が高く、スケーラブルな環境にデプロイできます。WebLogic Serverインスタンスのクラスタを構成して負荷を分散したり、ハード・ウェアや他の原因による失敗が発生した場合に余裕をもって対応したりするための機能が備わっています。新しく導入された診断ツールでは、システム管理者によるデプロイ済みアプリケーションおよびWebLogic Server環境自体のモニターおよびパフォーマンス・チューニングが可能です。また、人の手を煩わせず自動的にアプリケーションのスループットをモニターおよびチューニングするように構成することもできます。サービスへのアクセスは豊富なセキュリティ機能によって保護され、企業データをセキュアに保つことで悪意のある攻撃を防止できます。

図1-1では、全体的なOracle Fusion MiddlewareスタックにおけるWebLogic Serverの位置づけを示します。

図1-1 Oracle Fusion Middlewareの概要

プログラミング・モデル

WebLogic Serverでは、Java EE 6.0仕様を完全にサポートしています(http://www.oracle.com/technetwork/java/javaee/tech/index-jsp-142185.html)。詳細については、以下のWebLogic Serverのプログラミング・ガイドを参照してください。

- Webアプリケーションでは、サーブレットおよびJavaServerPages (JSP)のJava EE標準に基づいて動的なWebページをデプロイメントするための基本的なJava EEメカニズムが提供されます。Webアプリケーションは、HTMLページ、イメージ・ファイルなどの静的なWebコンテンツの提供にも使用されます。

- Webサービスでは、ネットワーク上の他のシステムで利用でき、分散型Webベース・アプリケーションのコンポーネントとしても使える、一連の共有機能が提供されます。

- XMLには、データ交換、コンテンツを表示とは無関係に格納する手段、などの機能があります。

- Java Messaging Service (JMS)を使用すると、メッセージを交換してアプリケーション同士で通信できます。メッセージとは、異なるアプリケーション間の通信を調整するために必要な情報が含まれている、リクエスト、レポート、およびイベントです。

- Java Database Connectivity (JDBC)では、DBMSリソースへのプール機能付きアクセスが提供されます。

- リソース・アダプタでは、EIS (エンタープライズ・インフォメーション・システム)への接続機能が提供されます。

- Enterprise JavaBeans (EJB)では、データおよびビジネス・ロジックをカプセル化するためのJavaオブジェクトが提供されます。

- Remote Method Invocation (RMI)は、アプリケーションでリモート・オブジェクト上のメソッドをローカルに呼び出せるようにする、分散オブジェクト・コンピューティングのJava標準です。

- セキュリティAPIを使用すると、お使いのJava EEアプリケーションに認証と認可の機能を統合できます。セキュリティ・プロバイダAPIを使用して、独自のカスタム・セキュリティ・プロバイダを作成することもできます。

- WebLogic Tuxedo Connectivity (WTC)では、WebLogic ServerアプリケーションとTuxedoサービス間の相互運用性が提供されます。WTCを使用すると、WebLogic ServerクライアントからTuxedoサービスを呼び出したり、サービス・リクエストにレスポンスするためにTuxedoクライアントからEJBを呼び出したりできます。

- 「WebLogic Serverアプリケーション開発の概要」では、開発者用ツールおよびWebLogic Serverアプリケーションのコーディングのベスト・プラクティスを提供します。

さらに、WebLogic Serverは、Javaプラットフォーム用のオープン・ソース・アプリケーション・フレームワークであるSpring Frameworkを使用して開発したアプリケーションをサポートします。『Oracle WebLogic ServerでのSpringサポート』では、Springアプリケーションを開発およびデプロイするときに使用されるSpringおよびWebLogic Serverサポートの概要を提供します。また、WebLogic ServerのためにSpringアプリケーションを書き込む方法の例を提供します。http://www.springsource.org/上でSpringSourceも参照してください。

高可用性

以下のWebLogic Serverの機能とツールにより、高可用性を備えたスケーラブルなアプリケーションのデプロイメントがサポートされています。

- WebLogic Serverクラスタでは、作業負荷を複数のWebLogic Serverインスタンスに分散することにより、アプリケーションにスケーラビリティと信頼性が提供されます。着信リクエストを、処理される作業量に基づいて、クラスタ内のWebLogic Serverインスタンスに転送できます。ハードウェアまたは他の原因により失敗が発生した場合、他のクラスタ・ノードでセッション状態を利用でき、そのノードで障害の起きたノードの作業を再開できます。さらに、クラスタを実装すると、サービスをホストするマシンが1台だけの場合にも、失敗発生時にはそのサービスを別のノードに移行できます。
HTTPセッション状態については、クラスタ内のサーバー群に渡るレプリケートに加えて、複数のクラスタに渡るレプリケートも可能なため、複数の地理的領域、電力供給網、インターネット・サービス・プロバイダに渡る可用性とフォールト・トレランスが拡張されています。

- ワーク・マネージャでは、定義したルールに基づいて、さらには実際の実行時パフォーマンスの統計をモニターすることによって、作業の優先順位を決められます。こうした情報は、後にアプリケーションのパフォーマンスを最適化するためにも使用されます。ワーク・マネージャはWebLogic Serverドメイン全体に対して適用することも、特定のアプリケーションやコンポーネントに適用することもできます。

- 過負荷保護機能では、過負荷状態の検出、回避、およびその状態からの回復ができます。

- ネットワーク・チャネルでは、ネットワークのトラフィックをその種類に基づいて複数のチャネルに分割することにより、ネットワーク・リソースの効率的な利用を簡単にできるようにします。

- WebLogic Server永続ストアは、永続性を必要とするWebLogic Serverのサブシステムおよびサービスに対する、組込み型の高性能なストレージ・ソリューションです。たとえば、永続JMSメッセージを格納したり、ストア・アンド・フォワード機能を使用して、メッセージを一時的に格納してから送信したりできます。永続ストアは、ファイルベースのストアまたはJDBC対応データベースの永続性をサポートします。

- ストア・アンド・フォワード・サービスを使用すると、複数のWebLogic Serverインスタンスに分散されているアプリケーション間でメッセージを確実に配信できます。ネットワークの問題やシステム障害が原因で、メッセージの送信時に宛先が使用不能になっている場合、メッセージはローカルのサーバー・インスタンスに保存され、リモートの宛先が使用可能になった時点で転送されます。

- 企業向け開発ツールを使用すると、開発フェーズから本番環境へのアプリケーションのデプロイメントと移行を簡単に行えます。

- 本番再デプロイメントを行うと、古いバージョンのエンタープライズ・アプリケーションで処理中の状態にある作業を中断せずに、新しいバージョンのアプリケーションをデプロイできます。

診断フレームワーク

WebLogic診断フレームワークはモニターおよび診断を行うサービスです。このサービスを使用すると、実行中のサーバーおよびそのサーバーにデプロイされているアプリケーションで生成された診断データの作成、収集、分析、アーカイブ、およびその診断データへのアクセスが可能になります。この診断データによってWebLogic Serverインスタンスとデプロイされているアプリケーションの実行時のパフォーマンスを把握できます。また、発生したフォルトやパフォーマンス・ボトルネックを特定したり診断したりすることも可能です。

セキュリティ

WebLogic Serverのセキュリティ・アーキテクチャでは、アプリケーションをWeb上で利用可能にする際のセキュリティ上の問題を扱うために設計された、包括的で柔軟性に富んだセキュリティ・インフラストラクチャが提供されています。WebLogicセキュリティは、WebLogic Serverアプリケーションを保護するためにスタンドアロンで使用することも、最高レベルのセキュリティ管理ソリューションを表す企業全体のセキュリティ管理システムの一部として使用することもできます。「WebLogicセキュリティ・サービスの概要」を参照してください。

クライアント・オプション

WebLogic Serverでは、ブラウザ・ベースのWebアプリケーション・クライアントに加えて様々な種類のクライアントがサポートされており、多機能なGUIアプリケーションを作成することも、簡単なコマンド・ライン・ユーティリティを作成することもできます。こうしたクライアントの種類には、RMI-IIOP、T3、Java SEクライアント、Java EEシン・クライアント、CORBA/IDLクライアント、BEA Tuxedoと通信するC++クライアントなどがあります。『Oracle WebLogic Serverスタンドアロン・クライアントのプログラミング』を参照してください。

Oracle WebLogic Suiteとの統合

WebLogic Serverは、統合されたOracle WebLogic Suite Javaインフラストラクチャ内でコア・アプリケーション・サーバー・ランタイムを提供します。この統合インフラストラクチャでは、アプリケーション・パフォーマンスとアプリケーションの可用性の向上ができます。また、これによって、アプリケーション・サービス品質が高まり、予測可能で信頼性のあるアプリケーション・スケーラビリティを実現できます。WebLogic Suiteでは、Oracle JDeveloperとEclipse用のOracle Enterpriseパックに基づいた生産的な高い開発ツール、およびOracle Enterprise Managerで大規模な管理と操作ができる完全な統合管理が含まれています。WebLogic Suiteの開発、ランタイムと管理機能は、ミッション・クリティカル・エンタープライズ・アプリケーションを実装するための基礎を提供します。

WebLogic Suiteは、以下のサーバー側コンポーネントで構成されています。

- Oracle WebLogic Server

- Oracle JRockit
Oracle JRockit JVMは、Intelアーキテクチャ用に最適化され、Javaアプリケーションの信頼性、スケーラビリティ、管理容易性、および柔軟性を確かなものにするために開発された、高パフォーマンスのJVMです。Oracle JRockit JVMを使用すると、32ビットまたは64ビット・アーキテクチャでのWindowsまたはLinuxオペレーティング・システム・プラットフォームにおいて、Javaアプリケーションを最適なパフォーマンスで実行できます。Oracle JRockit JVMはお使いのWebLogic Serverと共にインストールされています。「Oracle JRockit JVM」を参照してください。

- Oracle Coherence
Oracle CoherenceはOracle Fusion Middlewareのコンポーネントであり、このコンポーネントが提供する使用頻繁度の高いデータへの迅速かつ信頼性のあるアクセスを利用することで、企業はミッションクリティカルなアプリケーションを将来的に拡張させることができるようになります。Oracle Coherenceは自動的かつ動的に複数のサーバー上のメモリにデータを分割し、サーバーで障害が発生した場合でも、データの可用性およびトランザクションの整合性を保証します。Oracle Coherenceは共有インフラストラクチャとしてデータ局所性とローカル処理能力を組み合せることによって、リアルタイムのデータ分析、インメモリー・グリッド計算、トランザクションおよびイベントの並列処理を実行します。Oracle Coherenceは、3種類のエディションで提供されています。

Oracle Coherenceに関する詳細は、http://www.oracle.com/technology/products/coherence/index.htmlを参照してください。

- Oracle TopLink
Oracle TopLinkを使用して、永久性のあるオブジェクト指向のデータをリレーショナル・データベースに格納する高性能アプリケーションを構築できます。オブジェクト指向のデータはリレーショナル・データかXML (Extensible Markup Language)エレメントに変換されます。

Oracle TopLinkは高度なオブジェクト永続性およびオブジェクト変換フレームワークであり、開発と保守にかかる労力を削減して、エンタープライズ・アプリケーションの機能性を高める開発ツールと実行時機能を提供します。

Oracle TopLinkには、Java EEおよびJava SE環境でのEJB 3.0のサポートや、EJB 2.nのコンテナ管理の永続性(CMP)のサポートが含まれています。Oracle TopLinkは、Oracle WebLogic Server、OC4J、SunAS、JBoss、IBM WebSphereなどの様々なアプリケーション・サーバーと統合できます。

他のシステムとの統合

WebLogic Serverには、お使いのアプリケーションと様々なシステムを統合するためのツールが豊富に用意されています。これらのツールには、Webサービス、リソース・アダプタ、JMS .NETクライアント、JMS Cクライアント、およびJMSプロバイダ・オプション、アドバンスト・キューイングおよびRMIの統合に使用するツールが含まれています。

Webサーバーとの統合

WebLogic Serverをインストールすると、ApacheやMicrosoftのWebサーバーとWebLogic Serverを連携するためのプラグインも提供されます。通常は、これらのWebサーバーで静的なHTMLコンテンツを処理しながら、JSPなどの動的なWebコンテンツのリクエストをWebLogic Server環境に転送します。『WebLogic ServerのWebサーバー・プラグインの使用』を参照してください。

WebLogic Server APIのサンプルとサンプル・アプリケーション

WebLogic Serverをインストールすると、Java EE APIおよび他のWebLogic Serverの機能を示すサンプル・コードも提供されます。これらのサンプル・コードを利用しながら作業するには、WebLogic Serverをインストールする際にカスタム・インストール・オプションを選択し、WebLogic Serverのサンプルのインストールを選択します。サンプル・コードにアクセスするには、Windowsの「スタート」メニューにある「WebLogic Examples Server」を使用してWebLogic Serverサンプル・ドメインを起動するか、WL_HOME/samples/domains/wl_server (WL_HOMEはWebLogic Serverのインストール先ディレクトリ)にあるスクリプトstartWebLogicEx.cmdまたはstartWebLogicEx.shを起動します。サンプル・コードが利用可能な状態になれば、追加サンプルをダウンロードすることもできます。

上記のようにサンプル・コードをインストールすると、サンプル・コードと一緒に、Avitek Medical Records (MedRec)という完全なサンプル・アプリケーション(2つのバージョン)もインストールされます。

オリジナルのMedRec(WebLogic Serverの以前のバージョンに含まれていました)は、Java EEコンポーネントのあらゆる局面を簡潔にデモンストレートする、WebLogic Serverのサンプル・アプリケーション・スイートです。MedRecはあらゆるレベルのJava EE開発者に対応する学習用ツールとして設計されたものです。それは、各Java EEコンポーネントの使用方法、およびコンポーネントの対話やクライアント開発のベスト・プラクティスとなるデザイン・パターンを例示します。また、MedRecはWebLogic Server上でアプリケーションを開発するためのベスト・プラクティスを提示します。

MedRecのSpringバージョン(MedRec-Spring)は、Spring Frameworkを使用して再キャストしたMedRecです。WebLogic Server上でSpringアプリケーションを開発する場合は、MedRec-Springサンプル・アプリケーションをレビューしてください。SpringからのWebLogic Serverのエンタープライズ機能の利用方法を説明するために、コアJava EEコンポーネントをそれに対応するSpringに置き換えてMedRecを再構築しました。MedRec-Springでは、オリジナル・バージョンのMedRecの機能がSpringを使用して再実装されています。詳細は、MedRec-Springサンプルを参照してください。

MedRecを起動するには、Windowsの「スタート」メニューから「Medical Records Serverの起動」を選択するか、WL_HOME/samples/domains/medrec (WL_HOMEはWebLogic Serverのインストール先ディレクトリ)にあるスクリプトstartWebLogic.cmdまたはstartWebLogic.shを実行します。

MedRec-Springを起動するには、Windowsの「スタート」メニューから「Medical Records Server (Springバージョン)の起動」を選択するか、WL_HOME/samples/domains/medrec-spring (WL_HOMEはWebLogic Serverのインストール先ディレクトリ)にあるスクリプトstartWebLogic.cmdまたはstartWebLogic.shを実行します。

更新

以前のバージョンのWebLogic Serverに実装されているアプリケーションを現在のWebLogic Serverの環境に移行する際に役立つツールおよびドキュメントが提供されています。『Oracle WebLogic Serverアップグレード・ガイド』を参照してください。

2 システム管理

この章では、お使いの開発環境や本番環境のWebLogic Serverコンポーネントにおけるシステム管理の概要について説明します。

この章の内容は以下のとおりです。

- WebLogic Serverシステム管理の概要

- 管理タスクに応じた適切な技術の選択

- システム管理ツールおよびAPIの概要

- WebLogic Serverシステムの管理のためのロードマップ

WebLogic Serverシステム管理の概要

WebLogic Serverのシステム管理には、WebLogic Serverドメインの作成、アプリケーションのデプロイ、開発環境から本番環境へのドメインの移行、実行時システムのパフォーマンスの監視と管理、アプリケーションやシステム・リソースのセキュリティの構成および管理、問題の診断とトラブルシューティングなどの様々なタスクがあります。

WebLogic Serverでは、これらのタスクに役立つシステム管理者用のツールが多数用意されています。ブラウザ・ベースの管理コンソール、WLST (WebLogic Scripting Tool)、JythonをベースとしたWebLogicシステム管理タスクの自動化用のスクリプト言語、SNMP、構成ウィザード、コマンドライン・ユーティリティなどです。

WebLogic Serverの管理システムはJava EEおよびその他の標準に基づいているため、他のソフトウェアおよびハードウェア・コンポーネントの管理によく使用されるシステムと統合できます。さらに、WebLogic ServerにはJava EE Java Management Extension (JMX)仕様が実装されていて、WebLogic Server管理システムへのプログラム的なアクセスが可能です。このAPIを使用すると、カスタム管理ユーティリティを作成したり、Javaクラスを使用してよく使うタスクを自動化したりできます。

次の項に、お使いの開発環境または本番環境のWebLogic Serverコンポーネントにおけるシステム管理の概要を示します。

- 管理タスクに応じた適切な技術の選択

- システム管理ツールおよびAPIの概要

Weblogic Serverのインストールについては、『Oracle WebLogic Serverインストレーション・ガイド』を参照してください。

Oracle Enterprise Manager Fusion Middleware Control、Oracle Fusion Middlewareコマンド・ライン・ツール、Fusion Middleware Control MBeanブラウザなどのFusion Middleware管理ツールの使用については、Oracle Fusion Middleware管理者ガイドのOracle Fusion Middleware管理ツールの概要に関する項を参照してください。

管理タスクに応じた適切な技術の選択

表2-1に、一般的なシステム管理タスクと関連する技術を示します。

表2-1適切な管理技術の選択

これを行うには...

このテクノロジを使用します...

ドメインの作成

構成ウィザードを使用して、ターゲットの環境で使用するドメインを手順に従って作成または拡張します。『構成ウィザードによるドメインの作成』を参照してください。

ドメインの作成を自動化するには、コマンド・ラインから実行するJythonベースのスクリプト・インタフェースであるWebLogic Scripting Toolを使用します。『Oracle WebLogic Scripting Tool』のWLSTオフラインを使用してドメインの作成に関する項を参照してください。

または、WebLogic Serverのスキーマに準拠するドメイン構成のXMLファイルを作成します。『Oracle WebLogic Server ドメイン構成の理解』のドメイン構成ファイルに関する項を参照してください。

開発環境から本番環境へのドメインの移行

ドメイン・テンプレート・ビルダーのpackコマンドで、ドメインのスナップショットをJARファイルにアーカイブ化します。そのアーカイブをunpackコマンドで展開し、必要な起動スクリプト、特定のセキュリティ、および構成ファイルを作成します。『PackおよびUnpackコマンドによるテンプレートとドメインの作成』を参照してください。

ドメインの構成におけるトラッキングの変更

アクティブなドメインに対して構成を変更できる環境では、WebLogic Serverは構成ファイルのバージョン付きのアーカイブを自動的に保持します。『Oracle WebLogic Serverドメイン構成の理解』の構成ファイルのアーカイブに関する項を参照してください。

ドメイン構成の変更を示すリアルタイム通知を受け取るには、構成監査機能を有効にします。『Oracle WebLogic Serverの保護』のWebLogic監査プロバイダの構成に関する項を参照してください。

厳重に管理される本番環境では、実行時ドメインを読取り専用になるように構成します(『Oracle WebLogic Serverドメイン構成の理解』の構成の変更の制限に関する項を参照してください)。ステージング環境でテストして承認された変更を組み込む必要がある場合、読取り専用の設定を変更できます。または、ステージング環境を変更してテストしてから、Webサーバーを使用して本番環境からステージング環境にリクエストを再ルーティングできます。

Webサーバーへの接続の構成

Webサーバー・プラグイン。『Oracle WebLogic ServerにおけるWebサーバー・プラグインの使用』のWebLogic ServerにおけるWebサーバー・プラグインに関する項を参照してください。

データベースまたは他のシステムへの接続の構成

個々のアプリケーション内で、JDBCを使用して独自のデータ・ソースやデータベース接続を定義したり、リソース・アダプタを使用して外部システムに接続したりできます。そうしたアプリケーションをデプロイする際には、WebLogic Serverによってデータ・ソースと接続が作成されます。次を参照してください。

- 『Oracle WebLogic Server JDBCデータ・ソースの構成と管理』のWebLogic JDBCリソースの構成に関する項

- 『Oracle WebLogic Serverリソース・アダプタのプログラミング』のリソース・アダプタに関する項

アプリケーション内に独自のデータ・ソースまたは接続を定義していない場合、管理コンソールまたはWebLogic Scripting Toolを使用してリソースを作成できます。Oracle WebLogic Server管理コンソール・ヘルプ、または『Oracle WebLogic Scripting Tool』のWebLogic Scripting Toolの使用に関する項を参照してください。

サーバー・ライフサイクルの管理

ノード・マネージャは管理サーバーおよび管理対象サーバーをリモート・コントロールするユーティリティです。WebLogic Serverとは独立して実行され、管理サーバーおよび管理対象サーバーの起動と停止ができます。ノード・マネージャの使用は任意ですが、高可用性が要求されるアプリケーションをWebLogic Server環境でホストする場合に使用すると、ライフ・サイクル上のメリットが増大します。『Oracle WebLogic Serverノード・マネージャ管理者ガイド』のノード・マネージャによるサーバーの制御に関する項を参照してください。

ノード・マネージャを使用せずに管理サーバーまたは管理対象サーバーを起動するには、WebLogic Serverと一緒にインストールされるWebLogic Scripting Toolまたはスクリプトを使用します。『Oracle WebLogic Serverサーバーの起動と停止の管理』のサーバーの起動と停止に関する項を参照してください。

アクティブなドメインに対するサービスの変更または追加

WebLogic Server管理コンソールに、アクティブなドメインのサービスを変更したり追加したりするためのグラフィカル・ユーザー・インタフェースが提供されています。管理コンソール・ヘルプを参照してください。

コマンド・ライン・インタフェースで作業するには、対話モードでWebLogic Scripting Toolを使用します。『Oracle WebLogic Scripting Tool』のWebLogic Scripting Toolの使用方法に関する項を参照してください。

アプリケーション・サーバーのサービスおよびリソースのモニター

EJBコンテナ、サーブレット・コンテナ、JDBCデータ・ソースなどのサービスのパフォーマンスは、WebLogic Server管理コンソールからモニターします。

監視データのイベントを管理者に通知、またはJMXまたはJMSを通じて自動システムを統合するには、WebLogic診断フレームワークで監視ルールと通知を構成します。『Oracle WebLogic Server診断フレームワークの構成と使用』の監視と通知の構成に関する項を参照してください。

ユーザーのオペレーション・センターでSNMPを使用している場合、WebLogic Serverによって定義した実行時イベントに対してSNMP通知を送信できます。『Oracle WebLogic Server SNMP管理ガイド』を参照してください。

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

WebLogic Server管理コンソールに用意されているWebベースの一連のデプロイメント・アシスタントを使用して、デプロイ手順を実行できます。管理コンソール・ヘルプを参照してください。

アプリケーションのデプロイメント作業を自動化するには、WebLogic Scripting Toolを使用します。WebLogic Scripting Toolコマンド・リファレンスのデプロイメント・コマンドに関する項を参照してください。デプロイメントAPIを使用して、アプリケーションをデプロイするJavaプログラムを記述することもできます。『Oracle WebLogic Serverデプロイメントのプログラミング』を参照してください。

デプロイメント・ユーティリティおよびAPIの詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』のデプロイメント・ツールに関する項を参照してください。

アクティブなドメインでのアプリケーションの変更

デプロイされているアプリケーションの構成を変更するには、テキスト・エディタまたはIDEを使用してデプロイメント記述子を変更します。続いて、アプリケーションを再デプロイするか、デプロイメントAPIを使用して変更後のデプロイメント記述子をアップロードし、そのデプロイメント記述子をアプリケーション・コンテナに再読み込みさせます。

『Oracle WebLogic Serverへのアプリケーションのデプロイ』を参照してください。

アプリケーション内のアクティビティのモニター

モニターするデータ・ポイントを決めてから、JMXを通じてそのデータを公開する1つまたは複数のBeanを装備します。『Oracle WebLogic Server JMXによる管理可能なアプリケーションの開発』を参照してください。

または、WebLogic Server診断サービスを使用して実行中のアプリケーションにインストゥルメンテーション・コードを挿入し、そのアプリケーションのメソッドまたはそのアプリケーションと関わるトランザクションをモニターします。この技術は、利用可能なモニター用のメトリックをスキャンしても発見できない問題の原因を見つけるために使用します。アプリケーション内に問題があると判明した場合、JMXを使用してアプリケーションの状態の低下を示す属性を公開することで、その問題の再発を防止できます。『Oracle WebLogic Server診断フレームワークの構成と使用』を参照してください。

アプリケーションのパフォーマンスの最適化とサービス・レベル・アグリーメントの維持

ワーク・マネージャにより、アプリケーションにおいてどのように作業に優先順位を付けるかを構成します。ユーザーが定義したルールと実際の実行時パフォーマンスのモニター結果に基づいて、アプリケーションのパフォーマンスが最適化され、サービス・レベル・アグリーメントが維持されます。

『Oracle WebLogic Serverサーバー環境の構成』のワーク・マネージャを使用したスケジュールされた作業の最適化に関する項を参照してください。

管理通信の構成および保護

管理ポートを有効にすることにより、ドメイン内で管理トラフィックとアプリケーション・トラフィックを分離できます。本番環境では、この2つのトラフィックを分離すると、同じネットワーク接続上に大量のアプリケーション・トラフィックがある状態で重要な管理操作(サーバーの起動と停止、サーバーの構成の変更、およびアプリケーションのデプロイ)が行われることがなくなります。

管理ポートではSSLを使用した通信のみが受け入れられるため、管理リクエストを保護します。『Oracle WebLogic Serverサーバー環境の構成』の管理ポートと管理チャネルに関する項を参照してください。

ロギングおよびログ・ファイルの表示の構成

WebLogic Serverの多くの操作では、そのアクティビティのログが生成されます。各サーバーには、標準のHTTPアクセス・ログの他に、独自のログがあります。これらのログ・ファイルをさまざま方法で構成し、使用して、サーバーやアプリケーションの状態とアクティビティをモニターできます。

WebLogic Serverでは、デフォルトでログ・ファイルへのメッセージのフィルタ処理および記述には標準のJDKロギングAPIが使用されます。『Oracle WebLogic Serverログ・ファイルの構成とログ・メッセージのフィルタ処理』のWebLogicロギング・サービスに関する項を参照してください。

または、ログ・メッセージの配信にJakarta Project Log4j APIを使用するようにWebLogic Serverを構成することもできます。『ログ・ファイルの構成とログ・メッセージのフィルタ処理』のLog4jとCommons Logging APIに関する項を参照してください。

システム管理ツールおよびAPIの概要

WebLogic Serverには、独自の標準に基づいた拡張可能なユーティリティが複数用意されています。これらのユーティリティを使用してドメインを作成、管理、およびモニターできます。また、WebLogic Serverの管理APIを使用してカスタム管理ユーティリティを作成することもできます。

表2-2に、WebLogic Serverに同梱されているユーティリティを示します。

表2-2 管理ユーティリティ

ユーティリティ

説明

管理コンソール

管理コンソールは、管理サーバーでホストされるWebアプリケーション。アクティブなドメインの管理とモニターに使用します。以下のような管理機能があります。

- アクティブなドメインの構成

- サーバーの起動と停止

- サーバーの状態とパフォーマンスのモニター

- アプリケーションのパフォーマンスの監視

- サーバー・ログの表示

- スタンドアロンCoherenceキャッシュ・サーバーを制御(起動、停止、再起動)します。

- Coherenceクラスタの作成と構成

システム管理者は管理コンソールを使用することにより、JMX APIや基底の管理アーキテクチャについて理解していなくても、WebLogic Serverのすべての管理タスクを簡単に実行できます。管理サーバーでは、属性の変更内容を管理対象のドメインのconfig.xmlファイルに保持します。

次を参照してください。

- 管理コンソールの概要

- 管理コンソール・オンライン・ヘルプ(オンライン・ヘルプは、管理コンソール上部のツール・バーにある「ヘルプ」リンクをクリックしてもアクセスできます。)

WebLogic Scripting Tool

WebLogic Scripting Tool (WLST)は、コマンド・ラインから実行するスクリプト・インタフェース。アクティブまたは非アクティブなWebLogic Serverドメインの管理およびモニターに使用します。WLSTスクリプト環境は、Javaのスクリプト・インタプリタであるJythonをベースとしています。WebLogicのスクリプティング機能に加えて、ローカル変数、条件変数、フロー制御文などの一般的なインタプリタ言語機能も使用できます。WebLogicのスクリプト言語は、Jythonの言語構文に従って拡張できます。http://www.jython.orgを参照してください、

『Oracle WebLogic Scripting Tool』を参照してください。

構成ウィザード

構成ウィザードでは、WebLogic Serverドメインの適切なディレクトリ構造、config.xmlファイル、およびドメイン内のサーバーを起動するためのスクリプトを作成できます。このウィザードではドメインの作成にテンプレートを使用しており、テンプレートをカスタマイズすれば、ユーザー独自のドメインを複製できます。

構成ウィザードは、既存の非アクティブなドメインに対してサービスを追加または削除するためにも使用できます。

構成ウィザードは、グラフィカル・ユーザー・インタフェース(GUI)を通じて実行することも、テキスト・ベースのコマンド・ライン環境で実行することもできます。このコマンドライン環境はコンソール・モードと呼ばれます。このモードを管理コンソールと混同しないように注意してください。構成ウィザードでは、ユーザー定義のドメイン構成テンプレートを作成することもできます。

『構成ウィザードによるドメインの作成』を参照してください。

構成テンプレート・ビルダー

構成テンプレート・ビルダーを使用すると、独自のドメイン・テンプレートを簡単に作成できます。たとえば開発プロジェクト全体に標準ドメインを定義および伝達したり、あるいはドメインとそこで実行されるように開発されたアプリケーションを一緒に配布したりすることが可能になります。構成テンプレート・ビルダーで作成したテンプレートは、ターゲット環境向けにカスタマイズされたドメインを作成する土台となるように、構成ウィザードへの入力として使用されます。『ドメイン・テンプレート・ビルダーによるドメイン・テンプレートの作成』を参照してください。

Apache Antタスク

WebLogic Serverに用意されている2つのAntタスクは、開発環境で一般的な構成タスクを実行するのに役立ちます。Antとは、Makeに似たJavaベースの構築ツールです。構成タスクでは、WebLogic Serverインスタンスの起動と停止、WebLogic Serverドメインの作成と構成を行えます。他のWebLogic Antタスクと組み合わせると、カスタム・ドメインでアプリケーションの実証やテストを行うための強力なビルド・スクリプトを作成できます。

『Oracle WebLogic Serverアプリケーションの開発』のAntタスクを使用したWebLogic Serverドメインの構成に関する項を参照してください。

SNMPエージェント

WebLogic Serverには、Simple Network Management Protocol (SNMP)を使用してエンタープライズ全体の管理システムと通信する機能があります。WebLogic Server SNMPエージェントを使用すると、WebLogic Serverの管理をSNMPに準拠した管理システムに統合し、複雑に分散したシステムの様々なソフトウェアとハードウェアのリソースをまとめて表示できます。

『Oracle WebLogic Server SNMP管理ガイド』を参照してください。

表2-3に、独自の管理ユーティリティの作成に使用できるAPIを示します。

表2-3 管理API

API

説明

JMX

Java Management Extensions (JMX)は、ネットワーク上でリソースをモニターしたり管理したりするためのJava EEソリューション。JMXは、SNMPなどの管理規格と同様に、公開された仕様であり、一般的に使用されるモニタリング製品のベンダーの多くによってサポートされています。

JMX APIは、管理コンソール、WebLogic Scripting Tool、および他のWebLogic Serverユーティリティで使用されます。

『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』を参照してください。

Java EE管理API

Java EE管理API (JSR-77)により、ソフトウェア開発者は、任意のJava EEアプリケーション・サーバーでJDBC接続プールやデプロイ済みアプリケーションなどのリソースを検出および参照できる単一のJavaプログラムを作成することが可能になります。このAPI群はJava EEの管理仕様の一部。Java EEの管理仕様では、すべてのJava EE Webアプリケーション・サーバーは標準データ・モデルでリソースを記述する必要があります。

『Oracle WebLogic Server Java EE管理APIによるモニタリングと管理』を参照してください。

デプロイメントAPI

WebLogic ServerのデプロイメントAPIは、JSR-88のデプロイメント仕様を実装および拡張するものです。管理コンソール、wldeploy AntタスクなどのWebLogic Serverのすべてのデプロイメント・ツールでは、ドメイン内のアプリケーションの構成、デプロイ、および再デプロイにこのデプロイメントAPIを使用します。デプロイメントAPIを使用して、ユーザー独自のWebLogic Serverデプロイメント・ツールを構築したり、WebLogic Serverの構成およびデプロイメント操作をJSR-88対応の既存のツールと統合したりできます。

『Oracle WebLogic Serverデプロイメントのプログラミング』を参照してください。

WebLogic診断サービスAPI

WebLogic診断サービスには、サーバーの内部を可視性できる高度なモニター機能に加えて診断データへの動的なアクセスと制御もできる、標準化された一連のAPIがあります。このインタフェース群は、サーバーのコード・ベースの整合性を維持しつつ、将来のサード・パーティ製ツールの強化と統合を容易にするために標準化されています。このサービスは、サーバー、サーバーのスタック製品コンポーネントに適しており、主要ユーザーとして業務および管理スタッフを対象としています。

『Oracle WebLogic Server診断フレームワークの構成と使用』を参照してください。

ロギングAPI

WebLogic Serverでは、デフォルトでログ・ファイルへのメッセージのフィルタ処理および記述には標準のJDKロギングAPIが使用されます。『Oracle WebLogic Serverログ・ファイルの構成とログ・メッセージのフィルタ処理』のWebLogicロギング・サービスに関する項を参照してください。

または、ログ・メッセージの配信にJakarta Project Log4j APIを使用するようにWebLogic Serverを構成することもできます。詳細は、『Oracle WebLogic Serverログ・ファイルの構成とログ・メッセージのフィルタ処理』のLog4jとCommons Logging APIを参照してください。

WebLogic Serverシステムの管理のためのロードマップ

表2-4 WebLogic Serverシステムの管理のためのロードマップ

主要なタスク

サブタスクと追加情報

WebLogic Serverセキュリティの管理について

- WebLogic Serverドメインの概要

- WebLogic Serverクラスタの概要

- WebLogicセキュリティの概要

- 管理コンソールの概要

- Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発

- Oracle WebLogic Serverパフォーマンスおよびチューニング

WebLogic Serverのインストールとアップグレード

- Oracle WebLogic Serverインストレーション・ガイド

- 構成ウィザードによるドメインの作成

- サポート対象の構成

- Oracle WebLogic Serverの新機能

- Microsoft Windowsのリリース・ノート

- Linux x86のリリース・ノート

- WebLogic Serverの互換性

- Oracle WebLogic Serverアップグレード・ガイド

サーバー環境の構成

- システム管理ツールおよびAPIの概要

- 構成変更の管理

- Oracle WebLogic Server管理コンソール・ヘルプ

- Oracle WebLogic Scripting Tool

- ドメイン・テンプレート・ビルダーによるドメイン・ンプレートの作成

サーバーの起動と停止について

- サーバーの起動と停止の概要

- WebLogic Serverインスタンスのライフサイクルについて

- サーバー起動のコマンドライン・リファレンス

- サーバーの起動と停止のクイック・リファレンス

WebLogic Serverインスタンスの起動と停止

- シェル・スクリプトの使用

- 管理コンソールを使用する

- WLST (WebLogic Scripting Tool)の使用

- ノード・マネージャを使用したリモート・サーバーの制御

- クイック・リファレンスの使用

セキュリティの構成

- WebLogic Serverセキュリティの概要

- Oracle WebLogic Serverの保護

- 本番環境の保護

- Oracle WebLogic Serverロールおよびポリシーによるリソースの保護

サーバーとネットワーク通信の管理

- ネットワーク・リソースの構成

- Webサーバー機能の構成

- Oracle WebLogic ServerにおけるWebサーバー・プラグインの使用

システム・リソースの構成

- Oracle WebLogic Server JDBCデータ・ソースの構成と管理

- Oracle WebLogic ServerのJMS構成と管理

- WebLogicトランザクションの構成

- WebLogic Tuxedo Connectorの構成

- Oracle WebLogic Server WLECのためのWebLogic Tuxedo Connector移行ガイド

- 永続ストアの構成

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

- Oracle WebLogic Serverへのアプリケーションのデプロイ

- Webアプリケーションの構成

- XMLリソースの構成

- リソース・アダプタの構成

- Oracle WebLogic Server WebLogic Webサービスの紹介

ドメインの監視

- Oracle WebLogic Server診断フレームワークの構成と使用

- Oracle WebLogic Server SNMP管理ガイド

- Oracle WebLogic Serverログ・ファイルの構成とログ・メッセージのフィルタ処理

- Java EE管理APIによるモニタリングと管理

- 監視ダッシュボードの使用

高可用性を目的としたサーバー環境の構成

- クラスタ・アーキテクチャについて

- WebLogic Serverクラスタの設定

- クラスタ間でのセッション・レプリケーションの使用

- ワーク・マネージャを使用したアプリケーションの実行順序の優先付け

- 過負荷の回避と管理

WebLogic永続ストアについて

- WebLogic永続ストアの使用方法

- カスタム永続ストアの構成

- WebLogic永続ストアのチューニング

トラブルシューティング

- WebLogic Serverエラー・メッセージ・カタログの表示

- Oracle WebLogic Serverパフォーマンスおよびチューニング

- クラスタリングに関する一般的な問題のトラブルシューティング

- Oracle WebLogic Serverノード・マネージャ管理者ガイド

リファレンス

- Oracle WebLogic Server管理コンソールのためのアクセシビリティ・ノート

- Oracle WebLogic Serverコマンド・リファレンス

- Oracle WebLogic ServerのためのSNMP MIB

- WebLogic Scripting Toolコマンド・リファレンス

- Oracle WebLogic Server MBeanリファレンス

- Oracle WebLogic Serverスキーマのホーム

3 管理コンソールの概要

この章では、WebLogic Server管理コンソールの使用方法について説明します。

この章の内容は以下のとおりです。

- 管理コンソールについて

- 管理コンソールの起動

- 管理コンソールの要素

- チェンジ・センターの使用

管理コンソールについて

管理コンソールは、WebLogic Serverドメインの管理に使用するWebブラウザ形式のグラフィカル・ユーザー・インタフェースです。WebLogic Serverドメインは、論理的に関連付けられたWebLogic Serverリソースの集合であり、1つの単位として管理されます。ドメインには1つまたは複数のWebLogic Serverが含まれ、WebLogic Serverクラスタが含まれる場合もあります。クラスタはWebLogic Serverインスタンスのグループで、連携して動作することによりアプリケーションにスケーラビリティと高可用性がもたらされます。アプリケーションはドメインの一部としてデプロイされ、管理されます。

各ドメインでは、1つのWebLogic Serverインスタンスが管理サーバーとして構成されます。管理サーバーではWebLogic Serverドメインを一元的に管理できます。ドメイン内の他のすべてのWebLogic Serverインスタンスは、管理対象サーバーと呼ばれます。1つのWebLogic Serverインスタンスしか含まれないドメインでは、そのサーバーが管理サーバーおよび管理対象サーバーとして機能します。管理サーバーでは管理コンソールがホストされます。管理コンソールは、管理サーバーへのネットワーク・アクセスを持ち、サポートされたWebブラウザであればどのブラウザからでもアクセス可能なWebアプリケーションです。管理対象サーバーでは、アプリケーションがホストされます。

管理コンソールを使用すると、以下の操作ができます。

- WebLogic Serverインスタンスの構成、起動、停止

- WebLogic Serverクラスタの構成

- データベース接続(JDBC)、メッセージング(JMS)などのWebLogic Serverサービスの構成

- ユーザー、グループ、ロールの管理などのセキュリティ・パラメータの構成

- アプリケーションの構成とデプロイ

- サーバー・パフォーマンスとアプリケーション・パフォーマンスのモニター

- サーバー・ログ・ファイルとドメイン・ログ・ファイルの表示

- アプリケーションのデプロイメント記述子の表示

- 選択した実行時アプリケーションのデプロイメント記述子要素の編集

- スタンドアロンCoherenceキャッシュ・サーバーを制御(起動、停止、再起動)します。

- Coherenceクラスタの作成と構成

管理コンソール・オンライン・ヘルプ

管理コンソールには、詳細なヘルプ・システムがあります。ヘルプ・システムは次の2つの部分から構成されています。

- 操作ガイド。管理コンソールを介して実行できるタスクの手順が説明されています。

- 管理コンソール・リファレンス。管理コンソールで指定できる属性の説明など、管理コンソールの各ページに関する参照情報が示されています。

管理コンソール・オンライン・ヘルプは、管理コンソール自体からアクセスするか、または、オンラインでhttp://docs.oracle.com/cd/E24329_01/apirefs.1211/e24401/core/index.htmlにアクセスして参照することができます。

コンソール・エラー

管理コンソールの使用中に(情報、警告、エラー・メッセージなどの)メッセージが生成され、ログに記録できます。WebLogic Serverのログは、コンソールの「診断」>「ログ・ファイル」ページで参照できます。

管理コンソールの起動

この項では、管理コンソールの起動について説明します。

管理コンソールを使用するには、使用する環境でサポートされているWebブラウザを使用します。『Oracle WebLogic Serverの新機能』のサポートされている構成に関する項を参照してください。サポートされていないブラウザをご使用の場合、管理コンソールを使用するときに機能やフォーマットの面で問題が生じる可能性があります。

管理コンソールを起動するには:

1. 管理サーバーを起動します。

2. サポートされているいずれかのWebブラウザを起動し、次のURLを開きます。

http://hostname:port/console

ここで、hostnameは管理サーバーのDNS名またはIPアドレスで、portは管理サーバーでリクエストがリスニングされるリスニング・ポート(デフォルトでは7001)です。ドメイン全体の管理ポートを構成している場合は、そのポート番号を使用します。Secure Socket Layer(SSL)を使用するように管理サーバーが構成されている場合は、次のようにhttpの後にsを付加する必要があります。

https://hostname:port/console

注意:

ドメイン全体の管理ポートでは常にSSLを使用します。

3. ログイン・ページが表示されたら、管理サーバーを起動するために使用したユーザー名とパスワードを入力します(このユーザー名とパスワードはインストール・プロセス中に指定したものです)。または、Administrators、Operators、Deployers、Monitorsのいずれかのセキュリティ・グループに属するユーザー名を入力します。これらのグループでは、管理コンソールのシステム管理機能に対して様々なレベルでのアクセスが提供されています。
セキュリティ・システムを使用してユーザーをこうしたグループのいずれかに追加したり削除したりすることで、管理コンソールへのアクセスを制御できます。

注意:

ブラウザがHTTPリクエストをプロキシ・サーバーに送信するよう構成してある場合、管理サーバーのHTTPリクエストをプロキシに送信しないように、ブラウザを構成する必要があります。管理サーバーがブラウザと同じマシン上にある場合は、localhostまたは127.0.0.1に送信されるリクエストがプロキシに送信されないようにする必要があります。

管理コンソールの有効化

管理コンソールはデフォルトで有効になっています。無効にした場合には、WebLogic Scripting Tool (WLST)を使用して再び有効にできます。管理サーバーを起動してから、WLSTを起動して以下のコマンドを使用します。

例3-1 WLSTを使用したコンソールの再有効化

connect("username","password")
edit()
startEdit()
cmo.setConsoleEnabled(true)
save()
activate()
The following attribute(s) have been changed on MBeans which require server re-start.
MBean Changed : com.bea:Name=mydomain,Type=Domain Attributes changed :
ConsoleEnabled
Activation completed
disconnect()
exit()

WLSTの詳細は、『Oracle WebLogic Scripting Tool』を参照してください。

管理コンソールの要素

管理コンソールのユーザー・インタフェースには、以下のパネルがあります。

チェンジ・センター

チェンジ・センターは、管理コンソールを使用してWebLogic Serverに変更を加える際の作業の開始点です。「チェンジ・センターの使用」を参照してください。

図3-1 チェンジ・センター

「図3-1 チェンジ・センター」の説明

ドメイン構造

このパネルには、管理コンソール内のページの移動に使用できるツリー構造が表示されます。「ドメイン構造」ツリーの任意のノードを選択すると、対応するページが表示されます。「ドメイン構造」に表示されている+ (プラス)アイコンをクリックするとノードが展開され、- (マイナス)アイコンをクリックするとノードが折りたたまれます。

図3-2 ドメイン構造

「図3-2ドメイン構造」の説明

操作ガイド

このパネルには、管理コンソールの現在のページに関連するオンライン・ヘルプ・タスクへのリンクがあります。

図3-3 操作ガイド

「図3-3 操作ガイド」の説明

ツール・バー

管理コンソールの最上部にあるツール・バーには、次の要素があります。

ツール・バーの要素

説明

「ようこそ」メッセージ

管理コンソールにログインしたユーザー名が表示されます。

接続先

管理コンソールへの接続に使用したIPアドレスとポート。

ホーム

管理コンソールのトップ・ページへのリンク。

ログアウト

クリックするとコンソールからログ・アウトします。

プリファレンス

管理コンソールの動作の一部を変更できるページへのリンク。

記録

一連のWebLogic Scripting Tool (WLST)コマンドとして構成アクションの記録を開始します。コマンドをWLSTで再実行できる別のファイルに書き込みます。

Oracle WebLogic Server管理コンソール・ヘルプのWLSTスクリプトの記録に関する項を参照してください。

ヘルプ

管理コンソール・オンライン・ヘルプへのリンク。

検索

WebLogic Server構成MBeanを検索するため、MBean名に含まれている文字列を指定するためのテキスト・フィールド。

図3-4 ツール・バー

「図3-4 ツール・バー」の説明

ブレッドクラム・ナビゲーション

これまでにたどってきた管理コンソールのページを順に示す一連のリンクです。任意のリンクをクリックすると、以前に訪れたページへ戻れます。

図3-5 ブレッドクラム・ナビゲーション

「図3-5 ブレッドクラム・ナビゲーション」の説明

システム状態

「システム状態」パネルでは、ログに記録された情報メッセージ、エラー・メッセージ、および警告メッセージの数が報告されます。これらのメッセージはサーバーのログ・ファイルで参照できます。サーバーのログ・ファイルには、管理コンソールの「診断」>「ログ・ファイル」からアクセスできます。

図3-6 システム状態

「図3-6 システム・ステータス」の説明

チェンジ・センターの使用

管理コンソールを使用してWebLogic Serverドメインに変更を加える際の、作業の開始点になるのがチェンジ・センターです。チェンジ・センターを使用すると、ドメイン構成をロックしてから変更を加えることができます。これにより、その編集セッションの間、他のアカウントからは構成を変更できなくなります。「変更管理の機能について」を参照してください。

ドメイン構成ロックの機能は、本番ドメインでは常に有効になっています。開発ドメインでは有効にしたり無効にしたりできます。また、新しい開発ドメインを作成するときは、デフォルトで無効になっています。Oracle WebLogic Server管理コンソール・ヘルプのドメイン構成ロックの有効化と無効化に関する項を参照してください。

本番ドメインの構成を変更するには、次を行う必要があります:

1. 管理コンソール画面の左上部にある「チェンジ・センター」を見つけます。

2. 「ロックして編集」」ボタンをクリックして、ドメインの構成の編集階層をロックします。

3. コンソールの該当するページで必要な変更を行います。変更を行った各ページで「保存」をクリックします。

4. 必要な変更がすべて完了したら、「チェンジ・センター」の「変更のアクティブ化」をクリックします。

管理コンソールを使用して構成を変更したら、該当するページで「保存」(または「完了」)をクリックします。この操作によって、すぐに変更が有効になるわけではありません。変更は、「チェンジ・センター」の「変更のアクティブ化」をクリックしたときに有効になります。構成の変更は、この時にドメイン内の各サーバーに配信されます。各サーバーに変更が適用可能な場合、その変更内容は有効になります。変更を受け入れないサーバーがあった場合は、ドメイン内のすべてのサーバーからすべての変更がロールバックされます。変更は保留状態になり、その状態の変更を編集して問題を解決するか、元の状態に戻すかのどちらかを選択できます。

変更の取消し

「チェンジ・センター」の「すべての変更の取消し」をクリックすると、保留状態の(保存したがまだアクティブ化されていない)変更を一括で元の状態に戻せます。任意の変更を個別に元の状態に戻すには、管理コンソールの該当するページに移動して、属性を以前の値に戻します。

構成ロックの解放

構成ロックを解放するには、以下の手順を行います。

- 変更を行う前に、「チェンジ・センター」で「構成の解放」をクリックすると、ロックは明示的に解放されます。

- 変更を保存した後に、「チェンジ・センター」で「変更のアクティブ化」または「すべての変更を取消し」をクリックすると、ロックは暗黙的に解放されます。

管理サーバーを停止しても構成ロックは解放されません。管理サーバーが再び起動したとき、構成ロックは管理サーバーが停止された時点と同じ状態です。また、保留中の変更は保存されます。

変更管理の機能について

ドメイン内の構成の変更を配信するセキュアで予測可能な手段を提供するために、WebLogic Serverでは、大まかにいうとデータベース・トランザクションのような変更管理プロセスが必ず実行されます。ドメインの構成は、ファイル・システム上ではconfig.xmlファイルが中心となる一連のXML構成ファイルによって表現され、実行時には構成MBeanの階層によって表現されます。ドメインの構成を編集する場合、管理サーバー上の個々の構成MBeanの階層を編集することになります。編集プロセスを開始するには、編集する階層のロックを取得して他のユーザーが変更を行えないようにします。変更を完了したら、その編集階層の変更を保存します。変更をアクティブにしてドメイン内のすべてのサーバー・インスタンスに配信するまで、その変更は有効になりません。変更をアクティブ化すると、各サーバーでその変更を受け入れられるかどうかが判断されます。すべてのサーバーで変更を受け入れられる場合、各サーバーの作業用の構成階層が更新されて変更が完了します。

変更管理の詳細は、『Oracle WebLogic Serverドメイン構成の理解』の構成変更の管理に関する項を参照してください。

動的な変更と動的でない変更

管理コンソールで行った変更の一部は、アクティブ化するとすぐに反映されます。それ以外の変更については、その変更の影響を受けるサーバーまたはモジュールを再起動する必要があります。後者の変更は、動的でない変更と呼ばれます。管理コンソールでは、動的でない変更に対して警告のアイコンが示されます。

図nondynchange.gifの説明

動的な構成属性への変更は、その変更がアクティブ化されると有効になります。この場合、影響を受けるサーバーまたはシステムの再起動は必要ありません。この種の変更がサーバーおよび実行時階層で有効になるのは、変更がアクティブ化されたときです。動的でない構成属性への変更には、影響を受けるサーバーまたはシステム・リソースの再起動が必要です。変更は再起動の後に有効になります。

動的でない構成設定に変更があった場合、動的な構成設定に対する変更も再起動の後まで有効になりません。つまり、動的な属性と動的でない属性の編集を一度に行った場合、編集内容の一部分だけがアクティブ化されることはありません。

WebLogic Serverの変更管理プロセスは、ドメインまたはサーバーの構成データの変更に対して適用されます。セキュリティまたはアプリケーション・データには適用されません。

変更の表示

「チェンジ・センター」で「変更と再起動の表示」リンクをクリックすると、保存されたがまだアクティブ化されていない変更を表示できます。「変更と再起動の表示」リンクには、「変更リスト」と「再起動チェックリスト」の2つのタブがあります。

- 「変更リスト」ページには、保存されたがまだアクティブ化されていないすべての変更が表示されます。

- 「再起動チェックリスト」には、サーバーのうち、アクティブ化されている動的でない変更があって、それを有効にする前に再起動が必要なものがすべて表示されます。

4 WebLogic Serverドメイン

この章では、Oracle WebLogic Serverリソースの論理的に関連したグループであるWebLogic Serverドメインについて説明します。

この章の内容は以下のとおりです。

- ドメインについて

- ドメインの整理

- ドメインの内容

- WebLogic Serverドメインの理解のためのロードマップ

ドメインについて

Oracle WebLogic Serverの管理ドメインは、Oracle WebLogic Serverリソースの論理的に関連したグループです。ドメインには、管理サーバーと呼ばれる特殊なOracle WebLogic Serverインスタンスが含まれます。管理サーバーでは、ドメイン内のすべてのリソースを一元的に構成および管理します。通常は、管理対象サーバーと呼ばれるOracle WebLogic Serverインスタンスも含めてドメインを構成します。Webアプリケーション、EJB、Webサービスなどのリソースは管理対象サーバーにデプロイし、管理サーバーは構成や管理の目的にのみ使用します。

ドメインの整理

単一のOracle WebLogic Serverインストールを使用して複数のドメインを作成および実行したり、複数のインストールを使用して単一のドメインを実行したりできます。図4-1を参照してください。

図4-1 Oracle WebLogic Serverインストールとドメイン

「図4-1 Oracle WebLogic Serverインストールとドメイン」の説明

インストールされたOracle WebLogic Serverをどのようなドメインに構成するかは、ビジネス上のニーズによって異なります。システム管理者の責任範囲、アプリケーションの境界、サーバーを実行するマシンの設置場所などに応じて、複数のドメインを定義できます。また、ドメインを1つにして、すべてのOracle WebLogic Server管理アクティビティを一元化することも可能です。

特定のビジネス上のニーズやシステム管理者の慣習に応じて、次のような条件に基づいてドメインの構成を決定することができます。

- アプリケーションの論理的な区分。たとえば、ショッピング・カートのようなエンドユーザー機能専用のドメインと、バックエンドの会計アプリケーション専用のドメインを持つことができます。

- 物理的な場所。企業の所在地や支店ごとに別々のドメインを作成できます。物理的な場所ごとに、別々のOracle WebLogic Serverインストールが必要です。

- サイズ。ドメインをより効率的に管理したり、別々のシステム管理者が管理したりできるように、ドメインを小さな単位で構成することができます。一方、1つのドメインや少数のドメインにした方が、構成の一貫性を保ちやすくなります。

開発環境やテスト環境の場合は、単一のサーバー・インスタンスから構成されたシンプルなドメインを作成できます。この単一のインスタンスは管理サーバーとして動作し、開発中のアプリケーションをホストします。Oracle WebLogic Serverと一緒にインストールできるwl_serverドメインはこのタイプのサンプル・ドメインです。

ドメインの内容

図4-2に、管理サーバー、3つのスタンドアロンの管理対象サーバー、3つの管理対象サーバーを含むクラスタで構成された本番環境を示します。

ドメインの範囲と目的は多種多様ですが、ほとんどのOracle WebLogic Serverドメインには、この節で説明するコンポーネントが含まれます。

図4-2 ドメインの内容

「図4-2 ドメインの内容」の説明

管理サーバー

管理サーバーは、ドメイン全体の構成の一元的な制御エンティティとして動作します。ドメインの構成ドキュメントを管理し、構成ドキュメントでの変更を管理対象サーバーに配布します。また、ドメイン内のすべてのリソースを一元的に監視するための場所として使用することもできます。

管理サーバーと対話するには、管理コンソールまたはWLSTを使用するか、独自のJMXクライアントを作成します。ドメインの構成変更に関する詳細情報は、「システム管理」を参照してください。

各Oracle WebLogic Serverドメインには、管理サーバーとして機能する1つのサーバー・インスタンスが必要です。

管理サーバーおよびOracle WebLogic Server JMX管理システムにおける管理サーバーの役割の詳細情報は、「システム管理」を参照してください。

管理対象サーバーと管理対象サーバー・クラスタ

管理対象サーバーは、ビジネス・アプリケーション、アプリケーション・コンポーネント、Webサービス、およびそれらに関連付けられたリソースをホストします。また、パフォーマンスを最適化するため、ドメインの構成ドキュメントの読取り専用のコピーを保持します。管理対象サーバーを起動すると、その構成ドキュメントを管理サーバーに保持されているドキュメントと同期させるため、そのドメインの管理サーバーに接続します。

アプリケーションのパフォーマンス、スループット、または高可用性を向上させる必要のあるプロダクション環境では、複数の管理対象サーバーがクラスタとして動作するように構成できます。クラスタは、同時に動作し、連携して高度なスケーラビリティと信頼性を実現する複数のOracle WebLogic Serverインスタンスで構成されます。クラスタ内では、ほとんどのリソースとサービスが(単一の管理対象サーバーではなく)各管理対象サーバーに同じようにデプロイされています。1つのドメインには、クラスタとして構成されていない複数の管理対象サーバーだけでなく、複数のOracle WebLogic Serverクラスタを含めることができます。クラスタリングされた管理対象サーバーとクラスタリングされていない管理対象サーバーの主な違いは、フェイルオーバーとロード・バランシングのサポートです。これらの機能は、管理対象サーバーのクラスタでしか利用できません。Oracle WebLogic Serverクラスタのメリットと機能については、『Oracle WebLogic Serverクラスタの使用』のWebLogic Serverのクラスタリングに関する項を参照してください。

リソースとサービス

ドメインには、管理サーバーと管理対象サーバーだけでなく、管理対象サーバーやデプロイされたアプリケーションで必要となるリソースとサービスも含まれます。

管理対象サーバーでは、以下のリソースを使用できます。

- マシン定義 - 特定の物理的なハードウェアを識別します。マシン定義によって、コンピュータとそのコンピュータがホストする管理対象サーバーが関連付けられます。ノード・マネージャは、障害の発生した管理対象サーバーを再起動する際に、この情報を使用します。また、クラスタリングされた管理対象サーバーは、レプリケートされたセッション・データを格納する最適な場所を選択する際に、この情報を使用します。ノード・マネージャの詳細は、『Oracle WebLogic Serverノード・マネージャ管理者ガイド』のノード・マネージャの概要に関する項を参照してください。

- ネットワーク・チャネル - 管理対象サーバーがクライアントとの通信に使用するデフォルトのポート、プロトコル、およびプロトコル設定を定義します。ネットワーク・チャネルを作成したら、ドメイン内の任意の数の管理対象サーバーとクラスタに割り当てることができます。詳細は、『Oracle WebLogic Serverサーバー環境の構成』のネットワーク・リソースの構成に関する項を参照してください。

- 仮想ホスト - Oracle WebLogic Serverインスタンス(サーバー)またはクラスタが応答するホスト名のセットを定義します。仮想ホスト機能を使用する場合、DNSを使用して、サーバーまたはクラスタのIPアドレスにマップする1つまたは複数のホスト名を指定します。また、各仮想ホストでどのWebアプリケーションを処理するかについても指定します。

アプリケーションでは、以下のリソースおよびサービスを使用できます。

- セキュリティ・プロバイダ - 認証や認可など、セキュリティの特定の側面を処理するモジュール・コンポーネントです。

- リソース・アダプタ - エンタープライズ情報システム(EIS)に固有のシステム・ライブラリで、EISへの接続性を提供します。

- 診断およびモニター・サービス。

- JDBCデータ・ソース - アプリケーションからデータベースへの接続を可能にします。

- メール・セッション。

- XMLパーサーおよびトランスフォーマ・ファクトリのXMLエンティティ・キャッシュおよびレジストリ。

- メッセージング・サービス(JMSサーバー、ストア・アンド・フォワード・サービスなど)。

- 永続ストア - データ(永続JMSメッセージなど)を格納する物理リポジトリです。具体的には、JDBC対応のデータベースまたはディスク・ベースのファイルのどちらかです。

- 起動クラス - システム全体のカスタム・サービスをアプリケーションに提供するために作成するJavaプログラムです。

- ワーク・マネージャ - ユーザーが定義したルールに基づいて、アプリケーションが実行する作業の優先順位を決定し、実行時の実際のパフォーマンスを監視します。Oracle WebLogic Serverドメイン全体のワーク・マネージャを作成したり、特定のアプリケーション・コンポーネントのワーク・マネージャを作成したりできます。

- ワーク・コンテキスト - アプリケーションからリモート・コンテキストに、プロパティをリモート呼出しに含めずに渡すことを可能にします。

WebLogic Serverドメインの理解のためのロードマップ

表4-1 WebLogic Serverドメインの理解のためのロードマップ

主要なタスク

サブタスクと追加情報

WebLogic Serverドメインについてもっとよく知る

- 管理サーバーに障害が発生した場合

- ドメインの制限事項

- ドメイン構成ファイル

- 変更管理の概要

- システム管理

ドメインの作成

- 構成ウィザードによるドメインの作成

- 構成ウィザードの概要

- WebLogicドメインの拡張

- PackおよびUnpackコマンドによるテンプレートとドメインの作成

- WLSTオフラインを使用したWebLogicドメインの作成

ドメインの構成

- 既存のWebLogicドメインの構成

- Oracle WebLogic Serverドメインの構成の理解

- 構成変更の管理

ドメイン・テンプレートの操作

- ドメイン・テンプレート・ビルダーによるドメイン・テンプレートの作成

- ドメイン・テンプレートの作成および使用(オフライン)

サンプル

- WLSTオフライン・サンプル・スクリプト
また、WLSTオフラインおよびオンラインを使用してWebLogicドメイン・リソースを構成するサンプル・スクリプトは、Oracle Technology Networkサイトから入手できます。

リファレンス

- ドメイン・テンプレート・リファレンス

- ドメイン構成スキーマ

- ドメイン・セキュリティ・スキーマ

5 WebLogic Serverクラスタリング

この章では、WebLogic Serverクラスタ、即ち同時に動作し、連携して高度なスケーラビリティと信頼性を実現する複数のWebLogic Serverサーバー・インスタンスのグループについて説明します。

この章の内容は以下のとおりです。

- WebLogic Serverクラスタの概要

- クラスタとドメイン間の関係

- クラスタリングの利点

- クラスタの重要な機能

- クラスタリング可能なオブジェクトの種類

- クラスタリング不可能なオブジェクトの種類

- WebLogic Serverでのクラスタリングのためのロードマップ

WebLogic Serverクラスタの概要

WebLogic Serverクラスタは、同時に動作し、連携して高度なスケーラビリティと信頼性を実現する複数のWebLogic Serverサーバー・インスタンスで構成されます。クラスタはクライアントからは単一のWebLogic Serverインスタンスのように見えます。クラスタを構成する複数のサーバー・インスタンスは同じマシン上で実行することも、複数のマシンに分散配置することもできます。クラスタの能力は、既存のマシン上のクラスタにサーバー・インスタンスを追加することによって強化できます。また、新たにサーバー・インスタンスを配置するためのマシンをクラスタに追加することもできます。クラスタ内の各サーバー・インスタンスでは、同じバージョンのWebLogic Serverが動作している必要があります。

クラスタとドメイン間の関係

クラスタは特定のWebLogic Serverドメインの一部です。

ドメインとは、関連性があり1つの単位として管理されるWebLogic Serverリソースの集合のことです。ドメインには1つまたは複数のWebLogic Serverインスタンス(クラスタ化インスタンス、非クラスタ化インスタンス、またはクラスタ化インスタンスと非クラスタ化インスタンスの組合せが可能)が含まれます。ドメインには、複数のクラスタを構成できます。またドメインには、ドメインにデプロイされるアプリケーション・コンポーネントと、それらのアプリケーション・コンポーネントおよびドメイン内のサーバー・インスタンスが必要とするリソースおよびサービスも含まれます。アプリケーションおよびサーバー・インスタンスで使用されるリソースとサービスの例には、マシン定義、オプションのネットワーク・チャネル、コネクタ、起動クラスなどがあります。

WebLogic Serverインスタンスは、様々な基準によってドメインに分類できます。たとえば、ホストするアプリケーションの論理的な区分、地理的な考慮事項、あるいは管理対象リソースの数や複雑度に基づいてリソースを複数のドメインに割り当てることができます。ドメインの詳細は、『Oracle WebLogic Serverドメイン構成の理解』を参照してください。

各ドメイン内で、1つのWebLogic Serverインスタンスが管理サーバーとして機能します。このサーバー・インスタンスでは、ドメイン内のその他のサーバー・インスタンスおよびリソースのすべてを構成、管理、およびモニターします。各管理サーバーでは1つのドメインだけを管理します。ドメインに複数のクラスタが含まれる場合、ドメイン内の各クラスタは同じ管理サーバーによって管理されます。あるクラスタ内のすべてのサーバー・インスタンスは同じドメイン内になければなりません; 1つのクラスタを複数のドメインにまたがって「分割」することはできません。同様に、構成済みのリソースまたはサブシステムを複数のドメインで共有することはできません。

クラスタ化されたWebLogic Serverインスタンスの動作は、フェイルオーバーとロード・バランシングの機能を備えること以外は、クラスタ化されないインスタンスと同様です。クラスタ化されたWebLogic Serverインスタンスの構成に使用するプロセスおよびツールは、クラスタ化されないインスタンスの場合と同じです。ただし、クラスタリングによって可能になるロード・バランシングとフェイルオーバーの効果を実現するためには、クラスタの構成に関する特定のガイドラインに従う必要があります。

クラスタリングの利点

WebLogic Serverクラスタを利用することによってもたらされる利点には、次のものがあります。

- スケーラビリティ
WebLogic Serverクラスタにデプロイされるアプリケーションの能力を、必要に応じて動的に増強することができます。サービスを中断させることなく、つまり、クライアントおよびエンド・ユーザーへの影響なしにアプリケーションを動作させ続けながら、クラスタにサーバー・インスタンスを追加できます。

- 高可用性
WebLogic Serverクラスタでは、サーバー・インスタンスで障害が発生してもアプリケーションの処理を継続できます。アプリケーション・コンポーネントの「クラスタリング」は、クラスタ内の複数のサーバー・インスタンス上にコンポーネントをデプロイすることによって行います。そのため、コンポーネントが動作しているサーバー・インスタンスに障害が発生した場合、同じコンポーネントがデプロイされている別のサーバー・インスタンスがアプリケーションの処理を継続できます。

クラスタの重要な機能

この項では、スケーラビリティと高可用性を実現する重要なクラスタリングの機能を、技術的でない分かりやすい用語で定義します。

- アプリケーションのフェイルオーバー
フェイルオーバーとは、特定の「ジョブ」、つまり何らかの処理タスクの集合を実行しているアプリケーション・コンポーネントが何らかの理由によって使用不可になったときに、障害を起こしたオブジェクトのコピーがそのジョブを引き継いで完了することを意味します。

- 移行
WebLogic Serverでは、クラスタ化サーバー・インスタンスを、あるマシンから別のマシンに、自動的にまたは手動で移行できます。移行できる管理対象サーバーは、移行可能なサーバーと呼ばれます。この機能は、高可用性が求められる環境に向けて設計されています。

- ロード・バランシング
ロード・バランシングとは、環境内のコンピューティング・リソースおよびネットワーキング・リソース間で、ジョブとそれに関連する通信を均等に分配することです。

クラスタリング可能なオブジェクトの種類

クラスタ化されるアプリケーションまたはアプリケーション・コンポーネントは、クラスタ内の複数のWebLogic Serverインスタンス上で利用可能なものです。オブジェクトをクラスタリングすると、そのオブジェクトに対してフェイルオーバーとロード・バランシングが有効になります。クラスタの管理、保守、およびトラブルシューティングの手順を簡素化するには、オブジェクトを均一に、つまりクラスタ内のすべてのサーバー・インスタンスにデプロイします。

Webアプリケーションは、Enterprise JavaBeans (EJB)、サーブレット、Java Server Pages (JSP)などを含む様々な種類のオブジェクトで構成できます。それぞれのオブジェクトの種類ごとに、制御、呼び出し、およびアプリケーション内部での機能に関連する動作の一意の集合が定義されています。この理由から、クラスタリングをサポートし、またその結果としてロード・バランシングとフェイルオーバーを実現するためにWebLogic Serverで利用される手法は、オブジェクトの種類ごとに異なる可能性があります。WebLogic Serverのデプロイメントでは、次の種類のオブジェクトのクラスタリングが可能です。

- サーブレット

- JSP

- EJB

- Remote Method Invocation (RMI)オブジェクト

- Java Messaging Service (JMS)の宛先

- Coherenceサーバー

- タイマー・サービス

クラスタリング不可能なオブジェクトの種類

次のAPIおよび内部サービスは、WebLogic Serverでクラスタリングできません。

- ファイルの共有を含むFileサービス

WebLogic Serverでのクラスタリングのためのロードマップ

表5-1 WebLogic Serverでのクラスタリングのためのロードマップ

主要なタスク

サブタスクと追加情報

WebLogic Serverクラスタリングについてもっとよく知る

- サーブレットとJSPのクラスタリング

- EJBとRMIオブジェクトのクラスタリング

- JMSとクラスタリング

クラスタの構成

- クラスタの構成について

- クラスタでの通信

- クラスタ・アーキテクチャ

- WebLogic Serverクラスタの設定

- クラスタリングのベスト・プラクティス

クラスタでのロード・バランシングとフェイルオーバーについてもっとよく知る

- クラスタでのロード・バランシング

- クラスタのフェイルオーバーとレプリケーション

- クラスタを使用したBIG-IPハードウェアの構成

- MAN/WANフェイルオーバーに関するF5ロード・バランサの構成

- MAN/WANフェイルオーバーに関するRadwareロード・バランサの構成

クラスタ内のサーバーとサービスの移行

- サーバー全体の移行

- サービスの移行

トラブルシューティング

- 一般的な問題のトラブルシューティング

- マルチキャスト構成のトラブルシューティング

リファレンス

- WebLogicクラスタのAPI

6 WebLogic Serverでのアプリケーション開発

この章では、WebLogic Serverにおけるアプリケーション開発について説明します。

この章の内容は以下のとおりです。

- WebLogic ServerとJava EEプラットフォーム

- Java EEアプリケーションとモジュールの概要

- WebLogic Serverでのアプリケーション開発のためのロードマップ

WebLogic ServerとJava EEプラットフォーム

WebLogic Serverは、Java Platform, Enterprise Edition (Java EE)バージョン6.0技術を実装しています(http://www.oracle.com/technetwork/java/javaee/overview/index.htmlを参照)。Java EEは、Javaプログラミング言語に基づいた多層エンタープライズ・アプリケーションを開発するための標準プラットフォームです。Java EEを構成する技術は、いくつかのソフトウェア・ベンダーによって共同開発されました。Java EE 6アプリケーション開発に関する情報は、Java EE 6 チュートリアル(http://docs.oracle.com/javaee/6/tutorial/doc/)を参照してください。

Java EEプログラミング・モデルの重要な点は、メタデータ・アノテーションが導入されたことです。アノテーションを使用すると、コンテナ内でのアプリケーション・コンポーネントの動作、依存関係インジェクションのリクエスト方法などをJavaクラス自体の中で指定でき、アプリケーションの開発プロセスを簡略化できます。アノテーションは、エンタープライズ・アプリケーションの以前のバージョン(Java EE 1.4以前)で必要とされたデプロイメント記述子に代わるものです。

その焦点は、開発を容易にすることであり、Java EE 5から始まりJava EE 6でも引き継がれています。記述する必要があるコードが少なくなりました。定型コードの多くは削除され、可能なかぎりデフォルト値が使用され、アノテーションを広範に使用することによって、デプロイメント記述子の必要性が低減されています。

- EJB 3.1では、プログラミングおよびパッケージ化モデルの変更が簡素化されています。前のバージョンのJavaインタフェースを使用する必要がなくなり、プレーンな従来型Javaオブジェクトに注釈付けし、EJBコンポーネントとして使用できるようになりました。EJBモジュールをWebアプリケーションの内部に直接配置できるようになり、簡素化はさらに進みました。これにより、WebコンポーネントおよびEJBコンポーネントを格納するアーカイブを作成して、それらをEARファイルに結合する必要はなくなりました。

- Java EE 6では、簡略化されたWebサービスがサポートされるとともに、最新のWebサービスAPIが含まれており、サービス指向アーキテクチャ(SOA)には理想的な実装プラットフォームとなっています。

- JavaServer Faces (JSF)技術とJSP Standard Tag Library (JSTL)によって、Webアプリケーションが簡単に構築できるようになっています。Java EE 6では、AJAXなど、Web 2.0向けのアプリケーション構築のために豊富なシン・クライアント技術がサポートされています。

WebLogic Server Java EEアプリケーションは、標準化され、モジュール化されたコンポーネントに基づいています。WebLogic Serverでは、これらのモジュール用にあらゆるサービスが用意され、細かなアプリケーションの動作を、プログラミングを必要とせずに自動的に処理します。Java EEでは、モジュールの動作とパッケージ化が汎用的で移植性の高い方法で定義されています。このため、実行時構成はモジュールを実際にアプリケーション・サーバーにデプロイするときに行います。

Java EEには、Webアプリケーション、EJBモジュール、Webサービス、エンタープライズ・アプリケーション、クライアント・アプリケーション、およびコネクタのデプロイメント仕様が含まれています。Java EEでは、どのようにアプリケーションをターゲット・サーバーにデプロイするかは指定されておらず、標準のモジュールまたはアプリケーションをパッケージ化する方法のみが指定されています。この仕様では、モジュールのタイプごとに必要なファイルとそれらのディレクトリ構造上の格納場所が定義されています。

Javaはプラットフォームに依存しないので、任意のプラットフォームでコードの編集とコンパイルを行い、別のプラットフォームで稼働する開発用WebLogic Serverでアプリケーションをテストできます。たとえば、WebLogic ServerアプリケーションをWindowsまたはLinuxが動作しているPCで開発する場合、そのアプリケーションが最終的にどこにデプロイされるかを考慮する必要はありません。

詳細は、http://www.oracle.com/technetwork/java/javaee/tech/index-jsp-142185.htmlのJava EE仕様を参照してください。

Java EEアプリケーションとモジュールの概要

WebLogic Server Java EEアプリケーションは、WebLogic Server上で動作する以下のモジュールまたはアプリケーションのいずれかを含みます。

- Webアプリケーション・モジュール - HTMLページ、サーブレット、JavaServer Pages、および関連ファイル。『Oracle WebLogic Serverアプリケーションの開発』のWebアプリケーション・モジュールに関する項を参照してください。

- Enterprise JavaBeans (EJB)モジュール - エンティティBean、セッションBean、およびメッセージドリブンBean。『Oracle WebLogic Serverアプリケーションの開発』のEnterprise JavaBeanモジュールに関する項を参照してください。

- コネクタ・モジュール - リソース・アダプタ。『Oracle WebLogic Serverアプリケーションの開発』のコネクタ・モジュールに関する項を参照してください。

- エンタープライズ・アプリケーション - アプリケーションにパッケージ化されたWebアプリケーション・モジュール、EJBモジュール、リソース・アダプタ、およびアプリケーションにパッケージ化されたWebサービス。『Oracle WebLogic Serverアプリケーションの開発』のエンタープライズ・アプリケーションに関する項を参照してください。

- 『Oracle WebLogic Serverアプリケーションの開発』のWebLogic Webサービスに関する項を参照してください。

WebLogicアプリケーションには、以下のWebLogic固有のモジュールを含めることもできます。

- JDBCとJMSモジュールは、『Oracle WebLogic Serverアプリケーションの開発』のJMSとJDBCモジュールに関する項を参照してください。

- WLDF (WebLogic Diagnostic FrameWork)モジュールは、『Oracle WebLogic Serverアプリケーションの開発』のWebLogic Diagnostic Frameworkモジュールに関する項を参照してください。

WebLogic Serverでのアプリケーション開発のためのロードマップ

表6-1 WebLogic Serverでのアプリケーション開発のためのロードマップ

主要なタスク

サブタスクと追加情報

アプリケーション開発についてもっとよく知る

- XMLデプロイメント記述子

- デプロイメント・プラン

- WebLogic Serverアプリケーション開発のベスト・プラクティス

- アプリケーション・ライフサイクル・イベントについて

- 本番再デプロイメントについて

- WebLogic Serverアプリケーションのクラスローディングについて

- 共有Java EEライブラリおよびオプション・パッケージの概要

開発環境の設定

- WebLogic Serverの起動と停止

- 「分割開発ディレクトリ」を使用したアプリケーションの開発

アプリケーションの設計

- 共有のJava EEライブラリとオプション・パッケージによる、デプロイ済アプリケーション間でのコードの共有

- JSFおよびJSTLアプリケーションのプログラミング

- ライフサイクル・リスナーの使用

- HTTPパブリッシュ/サブスクライブ・サーバーの使用

- 『Oracle WebLogic Serverセキュリティのプログラミング』

- アプリケーションの国際化とローカライゼーション

- WebLogic Serverでのスレッドの使用

- Oracle WebLogic Serverアプリケーション・ロギングのためのロギング・サービスの使用

- Oracle WebLogic Serverスタンドアロン・クライアントのプログラミング

- 管理の容易なアプリケーションの設計

アプリケーションの構築

- 『Oracle WebLogic Serverアプリケーションの開発』

- WebLogic Serverへの「分割開発ディレクトリ」アプリケーションのデプロイ

- Antタスクを使用したJavaコードのコンパイル

開発ツールの使用

- 開発ソフトウェア

- WebLogic Development Mavenプラグイン

- Ant

- Oracle WebLogic Server管理コンソール・ヘルプ

- Oracle WebLogic Serverコマンド・リファレンス

- 構成ウィザードによるドメインの作成

- EJBGen

- ドメイン・テンプレート・ビルダーによるドメイン・ンプレートの作成

- Oracle WebLogic Scripting Tool

本番環境へのアプリケーションの移行

- アプリケーションまたはモジュールのデプロイメント準備

- 本番デプロイメントのためのアプリケーションの構成

- デプロイ済アプリケーションの更新(本番再デプロイメント)

アプリケーション・サンプル

- Java EE 6のサンプル

- 追加のAPIサンプル

- Avitek Medical Records
ソース・コードを含む、完全かつ機能的なJava EEアプリケーション。サンプル・アプリケーションのMedRec(Spring)では、Spring 3.0.xアプリケーションの開発例を示します。

Java EE APIプログラミング・ガイド

- Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発

- Oracle WebLogic Server JMXによる管理の容易なアプリケーションの開発

- Oracle WebLogic Serverセキュリティ・プロバイダの開発

- Oracle WebLogic ServerでのSpringのサポート

- Oracle TopLinkのソリューション・ガイド

- Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発

- Java EE管理APIによるモニタリングと管理

- Oracle WebLogic Server Enterprise JavaBeansのプログラミング

- Oracle WebLogic Server JDBCのプログラミング

- Oracle WebLogic Server JMSのプログラミング

- Oracle WebLogic Server JNDIのプログラミング

- Oracle WebLogic Server JTAのプログラミング

- Oracle WebLogic Serverリソース・アダプタのプログラミング

- Oracle WebLogic Server RMIのプログラミング

- Oracle WebLogic Server XMLのプログラミング

- Oracle WebLogic Serverスタンドアロン・クライアントのプログラミング

- Oracle WebLogic Serverデプロイメントのプログラミング

- Oracle WebLogic Server JCOMのプログラミング

- Oracle WebLogic Server JSPタグ拡張のプログラミング

- Oracle WebLogic Serverセキュリティのプログラミング

- Oracle WebLogic Server JAX-WS Webサービス・スタート・ガイド

- Oracle WebLogic Server Timer and Work Manager API (CommonJ)プログラマーズ・ガイド

- Oracle WebLogic Serverアプリケーション・ロギングのためのロギング・サービスの使用

- Oracle WebLogic Serverクラスタの使用

- Oracle WebLogic Server Tuxedo Connectorプログラマーズ・ガイド

JavadocおよびAPIリファレンス

- Java Platform, Enterprise Edition (Java EE)バージョン6.0

- Java Platform, Standard Edition (Java SE)バージョン6.0

- Oracle WebLogic Server JMS C APIリファレンス

- Oracle WebLogic Server APIリファレンス

- Oracle WebLogic ServerのためのMicrosoft .NET メッセージングAPI

一般的なリファレンス

- XMLデプロイメント記述子

- Oracle WebLogic Serverスキーマのホーム

- WebLogic JSPタグ(cache、process、repeat)

- WebLogic JSPフォーム検証タグ

- Oracle WebLogic Serverコマンド・リファレンス

- Oracle WebLogic Server MBeanリファレンス

- WebLogic Serverエラー・メッセージ・カタログ

7 WebLogic Serverでのアプリケーションのデプロイ

この章では、WebLogic Serverのアプリケーション・デプロイメントについて説明します。

この章の内容は以下のとおりです。

- デプロイメント・プロセスの概要

- Java EE 6デプロイメントの実装

- 迅速なデプロイメントのガイド

- WebLogic Serverでのアプリケーションのデプロイのためのロードマップ

デプロイメント・プロセスの概要

アプリケーション・デプロイメントという用語は、WebLogic Serverドメインにおいて、アプリケーションまたはモジュールをクライアント・リクエストの処理に使用できるようにするプロセスを指します。アプリケーション・デプロイメントは、一般的に次のタスクを伴います。

- アプリケーションおよびモジュールのデプロイメント準備

- 本番デプロイメントのためのアプリケーションの構成

- 新しい環境にデプロイするためのアプリケーションのエクスポート

- weblogic.deployerによるアプリケーションおよびモジュールのデプロイ

- 本番環境でのアプリケーションの再デプロイ

- デプロイされたアプリケーションの管理

Java EE 6デプロイメントの実装

WebLogic Serverは、Java EE 6仕様を実装しています。Java EE 6には、デプロイメント仕様JSR-88が含まれています。この仕様には、アプリケーションをアプリケーション・サーバーに構成およびデプロイする際に、デプロイメント・ツールおよびアプリケーション・サーバー・プロバイダで使用する標準APIが記述されています。

WebLogic Serverは、Java EEデプロイメント仕様に準拠するように、JSR-88サービス・プロバイダ・インタフェース(SPI)プラグインとモデル・プラグインの双方を実装しています。WebLogic Serverに対してJava EEアプリケーションおよびモジュールを構成、デプロイ、および再デプロイするには、(APIのWebLogic Server拡張を使用せずに) WebLogic Serverプラグインとともに基本的なJava EEデプロイメントAPIデプロイメント・ツールを使用できます。Java EEデプロイメントAPI構成プロセスで生成されたWebLogic Server構成は、図7-1に示すように、デプロイメント・プランおよび1つまたは複数の生成されたWebLogic Serverデプロイメント記述子ファイル内に格納されます。

図7-1 Java EEデプロイメントAPIによるアプリケーションの構成

「図7-1 Java EEデプロイメントAPIによるアプリケーションの構成」の説明

WebLogic Serverデプロイメント記述子は、WebLogic Server構成データを格納するために、必要に応じて生成されます。

Java EEデプロイメントAPIのデプロイメント・ツールで生成されたWebLogic Serverデプロイメント・プランにより、構成セッション中にアプリケーションのために生成されたWebLogic Serverデプロイメント記述子が識別されます。

Java EEデプロイメントAPIは、Java EE準拠のアプリケーション・サーバーで使用するためのアプリケーションおよびモジュールを構成する、簡単かつ標準化された方法を提供しますが、この仕様では以前のWebLogic Serverで利用できた多くのデプロイメント機能に対応していません。そのため、WebLogic Serverでは、Java EEデプロイメントAPI仕様に重要な拡張を行い、『Oracle WebLogic Serverへのアプリケーションのデプロイ』のWebLogic Serverのデプロイメント機能に関する項で説明されている機能をサポートしています。

迅速なデプロイメントのガイド

この項では、Java EEアプリケーションおよびモジュール、ならびにJSPおよびHTMLファイルを迅速にデプロイするための基本的な手順について説明します。また、システム管理者に向けて、ツールに関するヒントを示します。このページに記載のデプロイメント手順は、開発環境のみでの使用をお薦めします。本番環境での使用はお薦めしません。WebLogic Serverでアプリケーションを開発およびデプロイする方法の詳細は、『Oracle WebLogic Serverアプリケーションの開発』および『Oracle WebLogic Serverアプリケーションのデプロイ』を参照してください。

これらの高速な手順を実行する前に、『Oracle WebLogic Serverインストレーション・ガイド』を完了します。

Java EEデプロイメント

Java EEアプリケーションまたはモジュールをデプロイするには:

1. Java EEアプリケーションまたはモジュールに、名前を指定されたJDBCデータ・ソースやJMSキューなどの追加リソースが必要でないことを確認してください。アプリケーションに外部リソースが必要な場合は、そのアプリケーションをデプロイする前にターゲットWebLogic Serverでそれらの外部リソースの構成を行う必要があります。

2. Java EEアプリケーションまたはモジュールのアーカイブ・ファイルまたは展開されたアーカイブ・ディレクトリを、サンプル・サーバー・ドメインのディレクトリの/autodeployディレクトリ、つまり以下のディレクトリにコピーします。WL_HOME/samples/domains/wl_server/autodeploy

3. サンプルWebLogic Serverインスタンスを起動します。Windowsの場合は、「スタート」メニューのショートカット「サンプル・サーバーの起動」から起動することができます。

4. Javaクライアント、またはアプリケーションの構成済みURIを使用してアプリケーションにアクセスします。

自動デプロイメント

開発モードで実行している場合、WebLogic Serverはドメイン・ディレクトリの/autodeployサブディレクトリにコピーされたアプリケーションを自動的にデプロイします。自動デプロイメントは、評価またはテストを行うためのアプリケーションを簡単にすばやくデプロイする方法です。『Oracle WebLogic Serverへのアプリケーションのデプロイ』の開発ドメインでのアプリケーションの自動デプロイに関する項を参照してください。

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

管理コンソールを使用して複数のアプリケーションをデプロイする場合、インストール時には、これらのアプリケーションは管理コンソールの「デプロイメント」ページに「配布初期化中です」という状態でリストされています。変更をアクティブ化すると、「準備完了」状態でリストされるようになります。アプリケーションをデプロイするには、「デプロイメント」ページでアプリケーション名を選択して「起動」をクリックします。

システム管理者用ツール

システム管理者は、次のツールを使用して作業を開始できます。

- 管理コンソール
管理コンソールは、WebLogic Serverドメイン、サーバー・インスタンス、および実行中のアプリケーションと関連リソースを構成およびモニターできる、ブラウザ・ベースのWebアプリケーションです。管理コンソールはまた、新しいサーバー・インスタンスとクラスタの作成、およびアプリケーション記述子のチューニングにも使用できます。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプを参照してください。

インストール時に提示した資格証明を使用して管理コンソールにログインした後、「ヘルプ」ボタンまたは「操作ガイド」リンクをクリックすると詳細情報が表示されます。

- 構成ウィザード
WebLogic Server構成ウィザードを使用すると、新しいドメインの作成と、ドメインの構成を自動化するためのテンプレートの作成を行えます。詳細は、『構成ウィザードによるドメインの作成』を参照してください。

JSP/HTMLデプロイメント

単純なJSPまたはHTMLファイルをデプロイするには:

1. JSPファイルが、タグ・ライブラリやその他の外部リソースを参照していないことを確認してください - そうしたリソースは、これらの高速な手順の対象外となる追加のデプロイメント手順を必要とします。HTMLファイルには、このような制限はありません。

2. JSPまたはHTMLファイルをWL_HOME/samples/server/examples/build/mainWebAppディレクトリにコピーします。

3. サンプルWebLogic Serverインスタンスを起動します。Windowsの場合は、「スタート」メニューのショートカット「サンプル・サーバーの起動」から起動することができます。

4. Webブラウザで次のURLを使用して、JSPまたはHTMLファイルをリクエストします。
http://localhost:port/myFile

ここで:

localhostはWebLogic Serverが実行されているマシンのホスト名です。

portはWebLogic Serverがリクエストをリスニングしているポートの番号(デフォルトでは7001)です。

myF ileはステップ2でコピーしたJSPまたはHTMLファイルの、.jspまたは.html拡張子までを含めた完全な名前です。

JSPまたはHTMLファイルはあらかじめサンプル・サーバーをターゲットとするよう構成されたディレクトリから自動デプロイされています。デフォルトではmainWebAppがデプロイされており、mainWebApp展開ディレクトリに独自のJSPおよびHTMLファイルを入れて、それらを迅速に表示またはテストできます。

WebLogic Serverでのアプリケーションのデプロイのためのロードマップ

表7-1 WebLogic Serverでのアプリケーションのデプロイのためのロードマップ

主要なタスク

サブタスクと追加情報

アプリケーション・デプロイメントについてもっとよく知る

- デプロイメントの用語

- Java EE 6デプロイメントの実装

- WebLogic Serverのデプロイメント機能

- デプロイメント構成プロセスについて

- エクスポート・プロセスの概要

- アプリケーションのデプロイのベスト・プラクティス

アプリケーションのパッケージ化

- アプリケーションおよびモジュールのデプロイメント準備

- アーカイブ・ファイルと展開されたアーカイブ・デプロイメント

- wlpackage Antタスクの使用

デプロイメント・ツールの使用について

- デプロイメント・タスクの概要

- weblogic.Deployerユーティリティ

- WebLogic.Plan生成コマンドライン・リファレンス

- デプロイメント用のWebLogic Mavenプラグイン

- wldeploy Antタスク

詳細なトピック

- 一般的なデプロイメント・シナリオの概要

- デプロイメントのためのアプリケーションの構成

- 本番アプリケーションの再デプロイ

- Oracle WebLogic Serverデプロイメントのプログラミング

- 新しい環境にデプロイするためのアプリケーションのエクスポート

- 本番環境へのアプリケーションの配布

- デプロイメント順序の変更

- アプリケーションのオフライン化

- デプロイされたアプリケーションの管理

リファレンス

- WebLogicデプロイメントAPIについて

8 WebLogic Serverデータ・ソース

この章では、WebLogicのJDBC (Java Database Connectivity)データ・ソースについて説明します。

この章の内容は以下のとおりです。

- JDBCデータ・ソースについて

- 汎用データ・ソースについて

- GridLinkデータ・ソースについて

- JDBCマルチ・データ・ソースについて

- WebLogic Serverデータ・ソースのためのロードマップ

JDBCデータ・ソースについて

WebLogic Serverでは、JDBCデータ・ソースとマルチ・データ・ソースを構成してから、WebLogicドメイン内のサーバーまたはクラスタにJDBCリソースをターゲット指定またはデプロイすることで、データベース接続を構成できます。

Oracle WebLogic Serverでは3種類のデータ・ソースが提供されています。

- 汎用データ・ソース: 汎用データ・ソースとその接続プールによって、システムを効率よく稼働するのに役立つ接続管理プロセスが提供されます。アプリケーションや環境に合うようにデータ・ソースでオプションを設定できます。

- GridLinkデータ・ソース: Oracle RACインスタンスで状態の変化に順応して応答するイベント・ベースのデータ・ソース。

- マルチ・データ・ソース: マルチ・データ・ソースとは、ロード・バランシングやフェイルオーバー処理を提供する汎用データ・ソースのグループに関する抽象化です。

データベース接続の柔軟性と移植性を向上するようにプログラミングで定義できるJava EE DataSourceもWebLogic Serverでサポートされています。Java EE DataSourceに関する詳細は、『Oracle WebLogic Server JDBCのプログラミング』のDataSourceリソース定義に関する項を参照してください。

汎用データ・ソースについて

汎用データ・ソースを使用すると、データベースにアクセスし、データベース接続を管理できます。各データ・ソースには、データ・ソース作成時およびサーバー起動時に作成される、データベース接続のプールが含まれています。アプリケーションは、JNDIツリーまたはローカル・アプリケーション・コンテキストでデータ・ソースをルックアップし、次にgetConnection()を呼び出すことで、データ・ソースからのデータベース接続を予約します。接続の使用が終わったら、アプリケーションはできるだけ早くconnection.close()を呼び出して、データベース接続をプールに戻し、他のアプリケーションが使用できるようにする必要があります。

GridLinkデータ・ソースについて

1つのGridLinkデータ・ソースは、WebLogic ServerとOracle RACクラスタを含むOracle Databaseサービス間の接続を提供します。それは、Oracle RACインスタンス内の状態変更に対して適応的に応答するためにOracle Notification Service (ONS)を使用します。Oracle Databaseサービスは、共通属性を持つ作業負荷を表します。これにより、管理者は単一のエンティティとして作業負荷を管理できます。クラスタ内のノード数に関係なく、データベース内のサービス数が増加するに従い、GridLinkデータ・ソース数をスケールします。

GridLinkデータ・ソースには、汎用データ・ソースと次に示すOracle RACサポートの機能が含まれます。

- 高速接続フェイルオーバー

- ランタイム接続ロード・バランシング

- Oracle RAC停止時の正常操作

- GridLinkアフィ二ティ

- SCANアドレス

- Oracle Walletを使用してセキュアな通信

JDBCマルチ・データ・ソールについて

マルチ・データ・ソースとは、データ・ソースがJNDIツリーにバインドされるのと同じように、JDNDIツリーまたはローカル・アプリケーション・コンテキストにバインドされるデータ・ソースのグループ周辺を抽象化したものです。アプリケーションは、データ・ソースの場合と同じようにJNDIツリー上のマルチ・データ・ソースまたはローカル・アプリケーション・コンテキスト(java:comp/env)内のマルチ・データ・ソースをルックアップし、その後データベース接続をリクエストします。マルチ・データ・ソースは、そのマルチ・データ・ソースの構成内で選択されるアルゴリズムに応じて、リクエストを満たすためにロード・バランシングとフェイルオーバーのうちどちらのデータ・ソースを使用するかを決定します。

WebLogic Serverデータ・ソースのためのロードマップ

表8-1 WebLogic Serverデータ・ソースのためのロードマップ

主要なタスク

サブタスクと追加情報

WebLogic Serverデータ・ソースについてもっとよく知る

- WebLogic ServerにおけるJDBCリソースについて

- データ・ソース構成ファイル

- JDBCAリソースに対するJMXおよびWLSTのアクセス

- クラスタリングされたJDBCリソースの概要

- マルチ・データ・ソースの機能

- アプリケーションでのWebLogic JDBCの使用

JDBCの構成

- JDBCデータ・ソースの構成

- GridLinkデータ・ソースの使用

- JDBCマルチ・データ・ソースの構成

- Oracleドライバの高度な構成

- JDBCデータ・ソース・トランザクション・オプション

- JDBCデータ・ソースを保護するためのロールおよびポリシーの使用

Java EEデータ・ソース

- DataSourceリソース定義の使用

JDBCの管理

- データ・ソースの管理

- データ・ソースの監視

- GridLink JDBCリソースの監視

パフォーマンスおよびチューニング

- JDBCアプリケーションのチューニング

- データ・ソース接続プールのチューニング

WebLogic ServerでのOracle RACの使用

- WebLogic ServerでのOracle RACの使用

- Oracle RACでのマルチ・データ・ソースの使用

- Oracle RACでの接続時フェイルオーバーの使用

- Oracle RACでの高速接続フェイルオーバーの使用

JDBCドライバ

- サード・パーティJDBCドライバの概要

- Derby
Derbyは、WebLogic Serverに含まれる全面的なJava DBMS製品で、WebLogic Serverの例をサポートすることだけを目的としています。製品にはドキュメントは付属しておらず、http://db.apache.org/derby/manuals/index.htmlから入手可能です。Derbyの詳細は、http://db.apache.org/derbyを参照してください。

9 WebLogic Serverメッセージング

この章では、WebLogic ServerのJMS (Java Messaging System)について説明します。

この章の内容は以下のとおりです。

JMSとWebLogic Serverの概要

Java Message Service

WebLogic Serverメッセージングのためのロードマップ

JMSとWebLogic Serverの概要

JMSのWebLogic Server実装は、WebLogic Serverプラットフォームに緊密に統合されたエンタープライズ・クラスのメッセージング・システムです。JMS 1.1仕様(http://www.oracle.com/technetwork/java/jms/index.htmlで入手可能)を完全にサポートしています。また、標準JMS APIより高度なWebLogic JMS拡張も数多く用意されています。

Java Message Service

エンタープライズ・メッセージング・システムを使用すると、アプリケーション同士がメッセージを交換することによって非同期的に通信できます。メッセージとは、異なるアプリケーション間の通信を調整するために必要な情報が含まれている、リクエスト、レポート、およびイベントです。メッセージで提供される抽象化の階層により、宛先システムについての詳細情報をアプリケーション・コードから切り離すことができます。

Java Message Service (JMS)は、業界メッセージング・プロバイダによって実装されるエンタープライズ・メッセージング・システムにアクセスするための標準APIです。具体的なJMSの特長は以下のとおりです。

- メッセージング・システムを共有するJavaアプリケーション同士でメッセージを交換できます

- メッセージを作成、送信、および受信するための標準インタフェースによりアプリケーションの開発が容易になります

WebLogic JMSではクライアントとサーバーの両方のアプリケーションがサポートされており、Javaに加えて、C APIおよびMicrosoft .NET用のクライアント・ライブラリが含まれています。WebLogic JMSは、プロデューサ・アプリケーションからメッセージを受信し、そのメッセージをコンシューマ・アプリケーションに配信します。WebLogic ServerでのJMS APIのプログラミングの詳細は、『Oracle WebLogic Server JMSのプログラミング』を参照してください。WebLogic Serverにホストしたコンシューマ・アプリケーション用JMS APIプログラミングの詳細は、『Oracle WebLogic ServerメッセージドリブンBeanのプログラミング』を参照してください。

WebLogic JMSのアーキテクチャと環境

図9-1では、WebLogic JMSのアーキテクチャを示します。

図9-1 WebLogic JMSのアーキテクチャ

「図9-1 WebLogic JMSのアーキテクチャ」の説明

図9-1では、A1およびB1が接続ファクトリ、B2がキューです。

WebLogic JMSアーキテクチャの主要コンポーネントは以下のとおりです。

- JMSサーバー: JMSのキューおよびトピックのための管理対象メッセージ・コンテナ。宛先構成は、1つ以上のJMSサーバーをターゲットできるJMS XMLモジュールに存在し、1つの論理宛先を複数のJMSサーバーに分散できます。JMSサーバーの最も重要な役割は、JMSサーバーの宛先が受信するすべての永続メッセージに使用される永続ストアに関する情報を管理し、また、JMSサーバーの宛先で作成される恒久サブスクライバの状態を管理することです。ドメインごとに1つ以上のJMSサーバーを構成できます。1つのWebLogicサーバーでは複数のJMSサーバーを同時に起動でき、1つのJMSサーバーで1つ以上のモジュールを管理できます。詳細は、『Oracle WebLogic Server JMSの構成と管理』のJMSサーバーの概要に関する項を参照してください。

- JMS接続ホストおよび接続ファクトリ: クラスタ内のどのWebLogicサーバーでもJMSアプリケーション用のJMS接続ホストとして機能します。JMSアプリケーションは次の手順でWebLogic JMSへのアクセスを取得します。(a)JNDIから接続ファクトリ・リファレンスを取得します。(b)そのファクトリから接続を取得します。(c)その接続を通してメッセージを送受信します。JMSメッセージはアプリケーションからその接続ホストを経由して、接続ホストと同じクラスタに存在するJMSサーバー上の任意の宛先まで送信されます。アプリケーションでは、デフォルトの接続ファクトリ、またはJMSモジュールを使用して構成したカスタム接続ファクトリを利用できます。

- JMS宛先: JMSメッセージを保持し、JMSサーバーにホストされます。WebLogic JMSアプリケーションは、通常はJNDI経由でJMS宛先リファレンスを取得し、該当するJMS接続を使用してこれらの宛先に対してメッセージの送受信を行います。1つの論理WebLogic宛先を、同じクラスタ内の複数のJMSサーバーに分散されるように構成できます。WebLogic JMSクライアントは、クライアントの接続ホストと同じクラスタにホストされているどのWebLogic JMS宛先とでも透過的に通信できます。

- JMSモジュール: スタンドアロンのキューおよびトピック宛先、分散宛先、接続ファクトリなどの構成リソースを含み、weblogic-jms.xsdスキーマに準拠するXMLドキュメントによって定義されます。詳細は、『Oracle WebLogic Server JMSの構成と管理』のJMS構成リソースとはに関する項を参照してください。

- クライアントJMSアプリケーション: 宛先へのメッセージを生成するか、または宛先からのメッセージを消費します。

- JNDI (Java Naming and Directory Interface): JMS接続ファクトリおよび宛先用にルックアップ機能を提供します。

- WebLogic永続ストレージ: 永続メッセージ・データを保持するための、サーバー・インスタンスのデフォルト・ストア、ユーザー定義のファイル・ストア、またはJDBCでアクセス可能なユーザー定義ストア。

WebLogic Serverメッセージングのためのロードマップ

表9-1 WebLogic Serverメッセージングのためのロードマップ

主要なタスク

サブタスクと追加情報

WebLogic Serverメッセージングについてもっとよく知る

- WebLogic JMSのアーキテクチャと環境

- JMS構成リソース

- JMSサーバーの概要

- JMSモジュールの概要

- WebLogic JMSの環境関連システム・リソース

- メッセージング・モデルについて

- JMS APIについて

- パブリックJMS APIの付加価値拡張機能

WebLogic JMSのスタート・ガイド

- JMSプログラミングの概要

- JMS初級ユーザーおよび上級ユーザーのベスト・プラクティス

- 基本的なJMSアプリケーションの開発

- JMSリソースの構成の概要

- WebLogic Serverの付加価値JMS機能

- リモートおよび外部JMSプロバイダの統合

- サンプル・アプリケーションおよびサンプル・コード

- WebLogic JMSのトラブルシューティング

WebLogic JMSの新規機能の使用

- 高度なパブリッシュ/サブスクライブ・アプリケーションの開発

- Oracle Advanced Queueingとの相互運用

- Oracle WebLogic Server Oracle WebLogic Server Microsoft .NET対応のWebLogic JMSクライアントの使用

WebLogicメッセージングのプログラミング

- Oracle WebLogic Server JMSのプログラミング

- 高度なパブリッシュ/サブスクライブ・アプリケーションの開発

- Oracle WebLogic ServerメッセージドリブンBeanのプログラミング

WebLogicメッセージにおけるクライアントについて

- JMSクライアントについて

- WebLogic Serverクライアントの種類と機能

WebLogicメッセージングの構成

- JMS初級ユーザーおよび上級ユーザーのベスト・プラクティス

- Oracle WebLogic ServerのJMS構成と管理

- リモートおよび外部JMSプロバイダの統合

- Oracle WebLogic Serverストア・アンド・フォワードの構成と管理

- Oracle WebLogic Serverメッセージング・ブリッジの構成と管理

管理コンソールを使用したWebLogicメッセージングの構成

- JMSサーバーの構成

- JMSシステム・モジュールおよびリソースの構成

- JMSメッセージのストア・アンド・フォワードの構成

- メッセージング・ブリッジの構成と管理

パフォーマンスおよびチューニング

- WebLogic JMSのチューニング

- WebLogic JMSストア・アンド・フォワードのチューニング

- WebLogicメッセージング・ブリッジのチューニング

- メッセージドリブンBeanのチューニング

- ロギング・ラスト・リソースのチューニング

リファレンス

- WebLogic JMS拡張のJavadoc

- MBeanリファレンス

- JMSスキーマ

- Java Message Service仕様

- Oracle WebLogic Server JMS C APIリファレンス

- .NETクライアントのWebLogicメッセージングAPIリファレンス

10 WebLogic Serverセキュリティについて

この章では、WebLogic Serverのセキュリティ・サービスおよびWebLogic Serverの環境を保護する方法を紹介します。

この章の内容は以下のとおりです。

- WebLogic ServerでサポートされているJava EE 6のセキュリティ機能

- WebLogic Serverセキュリティ・サービスの概要

- WebLogic Serverセキュリティ・サービスのアーキテクチャ

- WebLogic Serverセキュリティの管理

- OPSS (Oracle Platform Security Services)

- WebLogic Serverの保護のためのロードマップ

WebLogic ServerでサポートされているJava EE 6のセキュリティ機能

WebLogic Serverでは、Java EE 6の次のセキュリティ機能がサポートされています。

- Java Authorization Contract for Containers (JACC) 1.4
JACC仕様では、Java EEアプリケーション・サーバーと認可ポリシー・プロバイダとの間の規約を定義しています。すべてのJava EEコンテナが、この規約をサポートしています。

JACC仕様では、Java EE認可モデルを満たすjava.security.Permissionクラスが定義されます。この仕様では、これらの権限クラスのインスタンスに対する操作への、コンテナのアクセス決定のバインディングが定義されます。新しい権限クラスを使用して、ロールの定義および使用を含む、Java EEプラットフォームの認可要件に対処する、ポリシー・プロバイダのセマンティクスが定義されます。

- Java Authentication Service Provider Interface for Containers (JASPIC) 1.0
JASPIC仕様では、メッセージ認証メカニズムを実装する認証プロバイダをクライアントまたはサーバーのメッセージ処理コンテナまたはランタイムに統合できる、サービス・プロバイダ・インタフェース(SPI)を定義しています。このインタフェースを介して統合された認証プロバイダは、呼出し側コンテナによって提供されたネットワーク・メッセージに対して操作を実行します。認証プロバイダは、受信コンテナがメッセージのソースを認証できるように、およびメッセージ送信者がメッセージの受信者を認証できるように、送信メッセージを変換します。認証プロバイダは受信メッセージを認証し、それを呼出し側コンテナに戻すと、メッセージ認証の結果としてIDが確立されます。

WebLogic Serverセキュリティ・サービスの概要

WebLogic Serverには、Webを介して使用できるアプリケーション用に一意でセキュアな基盤を提供するセキュリティ・アーキテクチャが含まれています。企業は、WebLogic Serverのセキュリティ機能を利用することで、Web上で使用できるアプリケーションの作成というセキュリティ課題に対処できるように設計された、包括的で柔軟性の高いセキュリティ・インフラストラクチャのメリットを得ることができます。WebLogicセキュリティは、WebLogic Serverアプリケーションを保護するためにスタンドアロンで使用することも、最高レベルのセキュリティ管理ソリューションを表す企業全体のセキュリティ管理システムの一部として使用することもできます。

WebLogicセキュリティ・サービスの主な特徴は、以下のとおりです。

- 包括的な標準ベースの設計。

- メインフレームからWebブラウザまでを網羅する、WebLogic Serverをホストとしたアプリケーション向けのエンドツーエンド・セキュリティ。

- レガシー・セキュリティ方式をWebLogic Serverセキュリティに統合することによって、企業の既存投資を活用できます。

- 融通性の高い統一されたシステムに組み込まれ、企業全体にわたるセキュリティ管理を容易化するセキュリティ・ツール。

- 企業のビジネス・ルールをセキュリティ・ポリシーにマッピングするため、ビジネス要件に対するアプリケーション・セキュリティのカスタマイズが容易です。

- Java EEリソースおよびアプリケーション定義のリソースに、同じモデルに従ってセキュリティ・ポリシーを適用できます。

- セキュリティ・ポリシーの容易な更新。このリリースでは、セキュリティ・ポリシーだけでなく、WebLogicリソースへのアクセスを制御する式の作成が、より容易に行えるようになっています。

- カスタマイズされたセキュリティ・ソリューションへの適合が容易です。

- モジュール化されたアーキテクチャなので、特定の企業の要件を満たすようにセキュリティ・インフラストラクチャを時間を追って変更できます。

- 遷移方式またはアップグレード・パスの一部として、複数のセキュリティ・プロバイダの構成をサポート。

- セキュリティの詳細とアプリケーション・インフラストラクチャを分離することにより、要件の変化に合わせたセキュリティのデプロイ、管理、維持、および修正を容易化。

- そのまま使用できる実践的セキュリティ方式を提供する、デフォルトのWebLogicセキュリティ・プロバイダ。このリリースでは、その他の認証ストア(データベースなど)をサポートし、選択したセキュリティ・プロバイダによって使用されるデータ・ストアとして、外部RDBMSシステムを構成することができます。

- カスタム・セキュリティ・プロバイダを使用したセキュリティ・スキームのカスタマイズ。

- WebLogic Server管理コンソールを使用して、セキュリティ・ルール、セキュリティ・ポリシー、およびセキュリティ・プロバイダを統一して管理できます。

- JAAS (Java Authentication and Authorization Service)、JSSE (Java Secure Socket Extension)、JCE (Java Cryptography Extension)、JACC (Java Authorization Contract for Containers)などの標準のJava EEセキュリティ技術をサポートしています。

- SAML (Security Assertion Markup Language) 1.1および2.0のサポートを含む、Webサービス・セキュリティの基盤。

- Webサイト、Webアプリケーション、デスクトップ・クライアントでのシングル・サインオン(SSO)へのWebLogic Serverの参加を可能にします。

- 証明書のルックアップ、検証、失効だけでなく、証明書レジストリも含む公開鍵管理のためのフレームワーク。

WebLogic Serverセキュリティ・サービスのアーキテクチャ

この節では、WebLogicセキュリティ・サービスのアーキテクチャについて説明します。アーキテクチャは、以下の節で説明する5つの主要なコンポーネントで構成されています。

- WebLogicセキュリティ・フレームワーク

- WebLogicセキュリティ・フレームワークによるシングル・サインオン

- WebLogic WebサービスでのSAMLトークン・プロファイルのサポート

- セキュリティ・サービス・プロバイダ・インタフェース(SSPI)

- WebLogicセキュリティ・プロバイダ

WebLogicセキュリティ・フレームワーク

図10-1では、WebLogicセキュリティ・フレームワークの概観を示します。フレームワークは、weblogic.security.serviceパッケージのインタフェース、クラス、および例外で構成されます。

図10-1 WebLogicセキュリティ・サービスのアーキテクチャ

WebLogicセキュリティ・フレームワークの主な役割は、簡素化されたアプリケーション・プログラミング・インタフェース(API)を提供することです。APIは、セキュリティ・サービスを定義するセキュリティ開発者およびアプリケーション開発者によって使用されます。そのコンテキスト内でWebLogicセキュリティ・フレームワークは、WebLogicコンテナ(WebおよびEJB)、リソース・コンテナ、セキュリティ・プロバイダの間の仲介役としても機能します。

WebLogicセキュリティ・フレームワークによるシングル・サインオン

SSO (シングル・サインオン)は、ユーザーが一度アプリケーション・コンポーネントにサインオンすれば、他の様々なアプリケーション・コンポーネントに(それらが独自の認証方式を使用している場合でも)アクセスできる機能です。シングル・サインオンを使用すると、ユーザーはすべてのアプリケーション、Webサイト、メインフレーム・セッションに、1つのIDでセキュアにログインできます。SAML (Security Assertion Markup Language)およびWindows統合認証機能は、WebLogic ServerアプリケーションにおいてWebベースのSSO (シングル・サインオン)機能を提供します。

WebLogic WebサービスでのSAMLトークン・プロファイルのサポート

WebLogic WebサービスとWebLogicセキュリティ・フレームワークは、SAML 1.1および2.0アサーションの生成、消費および検証をサポートします。SAMLアサーションを使用する場合は、WebサービスがSAMLアサーションとそれに付随する証明データをWebLogicセキュリティ・フレームワークに渡します。SAMLアサーションが有効で信頼されれば、フレームワークが認証されたサブジェクトと信頼性のあるプリンシパルをWebサービスに返します。WebLogic WebサービスとWebLogicセキュリティ・フレームワークでは、次のSAMLアサーションがサポートされます。

- Sender-Vouches - サブジェクトとは異なるアサーション側がサブジェクトの検証を保証します。受信側がアサーション側との信頼関係を確立している必要があります。

- Holder-of-Key -「holder-of-key」サブジェクト確認が指定されたSAMLトークンは、リクエスト・メッセージの整合性を確保するために、受信側で信頼されていない可能性のあるX.509証明書をサブジェクトで使用できるようにすることを目的としたものです。
理論的には、アサーション側によってX.509のパブリック証明書(または他のキー情報)がSAMLアサーションに挿入されます(厳密には、アサーション・パーティによりキーがサブジェクトにバインドされます)。この組み込まれた証明書を保護するには、SAMLアサーション自体がアサーティング・エンティティによって署名されている必要があります。WebLogic Serverの場合、SAMLアサーションはWebサービス・クライアントによって署名され、署名にはWebサービス・クライアントの秘密鍵が使用されます。つまり、アサーションの署名はSAML権限の署名であり、アサーションに含まれる証明書やアサーションにより特定される証明書に基づくものではありません。

- Bearer - アサーションのサブジェクトはアサーションのベアラーであり、アサーションの<SubjectConfirmationData>要素に含まれている属性を使用した確認に対するオプションの制約に従います。

セキュリティ・サービス・プロバイダ・インタフェース(SSPI)

WebLogic Serverのセキュリティは、一連のSSPI (セキュリティ・サービス・プロバイダ・インタフェース)に基づいています。開発者およびサード・パーティ・ベンダーは、SSPIを使用してWebLogic Server環境向けのセキュリティ・プロバイダを開発できます。SSPIは、認証、IDアサーション、認可、監査、裁決、ロール・マッピング、資格証明マッピング、および証明書の検索と検証に利用可能です。

SSPIを使用すると、カスタム・セキュリティ・プロバイダでWebLogic Serverリソースを保護することができます。SSPIを使用してカスタム・セキュリティ・プロバイダを開発することも、サード・パーティ・ベンダーからカスタム・セキュリティ・プロバイダを購入することもできます。

カスタム・セキュリティ・プロバイダの開発の詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』を参照してください。

WebLogicセキュリティ・プロバイダ

セキュリティ・プロバイダは、WebLogic Serverのセキュリティ・レルムに「プラグイン」してアプリケーションにセキュリティ・サービスを提供するためのモジュールです。セキュリティ・プロバイダは、アプリケーションのかわりにWebLogicセキュリティ・フレームワークに働きかけを行います。

WebLogic Server製品に付属しているセキュリティ・プロバイダがセキュリティ要件を完全に満たしていない場合には、カスタム・セキュリティ・プロバイダで補足するか、あるいはカスタム・セキュリティ・プロバイダに置き換えることができます。カスタム・セキュリティ・プロバイダは以下のようにして開発します。

- weblogic.security.spiパッケージから適切なセキュリティ・サービス・プロバイダ・インタフェース(SSPI)を実装してセキュリティ・プロバイダの実行時クラスを作成します。

- MBean定義ファイル(MDF)を作成し、WebLogic MBeanMakerユーティリティを使用してMBeanタイプを生成します。MBeanタイプは、セキュリティ・プロバイダの構成と管理に使用します。

詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』を参照してください。

WebLogic Serverセキュリティの管理

この節では、以下のトピックを取り上げます。

- セキュリティ・レルム

- セキュリティ・ポリシー

セキュリティ・レルム

セキュリティ・レルムは、WebLogicリソースを保護する複数のメカニズムで構成されています。各セキュリティ・レルムは、構成済みのセキュリティ・プロバイダ、ユーザー、グループ、セキュリティ・ロール、およびセキュリティ・ポリシーで構成されます。ユーザーはセキュリティ・レルムで定義されていないと、そのセキュリティ・レルムに属するWebLogicリソースにアクセスできません。ユーザーが特定のWebLogicリソースにアクセスしようとした場合、WebLogic Serverは、関連するセキュリティ・レルムでそのユーザーに割り当てられているセキュリティ・ロールと、その特定のWebLogicリソースのセキュリティ・ポリシーをチェックして、ユーザーを認証および認可します。

セキュリティ・ポリシー

セキュリティ・ポリシーはアクセス制御リスト(ACL)にかわるもので、「誰がWebLogicリソースにアクセスできるか」という問いに答えるものです。セキュリティ・ポリシーは、WebLogicリソースと、1つまたは複数のユーザー、グループ、またはセキュリティ・ロールとの間に関連付けを定義するときに作成されます。また、セキュリティ・ポリシーに日時制約を定義することもできます。WebLogicリソースにセキュリティ・ポリシーが割り当てられている場合、それに保護が設定されます。

セキュリティ・ポリシーは、定義済みの任意のWebLogicリソース(EJBリソースやJNDIリソースなど)、またはWebLogicリソースの特定のインスタンス(Webアプリケーション内のEJBメソッドやサーブレット)の属性または操作に割り当てることができます。セキュリティ・ポリシーをWebLogicリソースのタイプに割り当てると、そのリソースのすべての新しいインスタンスがそのセキュリティ・ポリシーを継承します。個々のリソースまたは属性に割り当てられたセキュリティ・ポリシーは、WebLogicリソースのタイプに割り当てられたセキュリティ・ポリシーをオーバーライドします。

OPSS (Oracle Platform Security Services)

OPSS (Oracle Platform Security Services)を使用することで、エンタープライズ製品開発チーム、システム・インテグレータ(SI)、および独立系ソフトウェア・ベンダー(ISV)は、標準ベースで移植可能なエンタープライズ・レベルの統合セキュリティ・フレームワークに基づいて、Java Standard Edition (Java SE)アプリケーションおよびJava Enterprise Edition (Java EE)アプリケーションを開発できます。

OPSSでは、標準ベースのアプリケーション・プログラミング・インタフェース(API)の形式で抽象化レイヤーが提供されているため、開発者はセキュリティやID管理の実装についての詳細を意識する必要がありません。OPSSを使用すれば、開発者は、暗号鍵管理や、ユーザー・リポジトリおよびその他のID管理インフラストラクチャとの相互作用について詳しく理解する必要はありません。OPSSを使用することで、自社開発のアプリケーション、サード・パーティ製のアプリケーション、および統合アプリケーションはすべて、企業全体で同じ共通のセキュリティ、ID管理、および監査サービスを使用できるようになります。OPSSは、WebLogic Serverに含まれています。

WebLogic Serverの保護のためのロードマップ

表10-1 WebLogic Serverの保護のためのロードマップ

主要なタスク

サブタスクと追加情報

セキュリティに関する基礎概念についてもっとよく知る

- 監査

- 認証

- SAML (Security Assertion Markup Language)

- SSO (シングル・サインオン)

- 認可

- IDと信頼

- セキュア・ソケット・レイヤー(SSL)

- WebLogicセキュリティ・フレームワーク

- WebLogicセキュリティ・フレームワークによるシングル・サインオン

- WebLogic WebサービスでのSAMLトークンのサポート

- Security Service Provider Interfaces (SSPI)

- WebLogicセキュリティ・プロバイダ

WebLogic Serverセキュリティの管理

- セキュリティ管理の概要

- デフォルト・セキュリティ構成のカスタマイズ

- セキュリティ・データの移行

- 組込みLDAPサーバーの管理

- RDBMSセキュリティ・ストアの管理

- IDおよび信頼の構成

- SSLの構成

- WebLogicドメインのセキュリティの構成

- 互換性セキュリティの使用

- ロールおよびポリシーによるWebLogicリソースの保護

- クラスタ・アーキテクチャのセキュリティ・オプションの確認

ユーザー認証

- LDAPサーバーで定義されたユーザーの認証

- RDBMSシステムに対しての認証

- Windows NTドメインに対しての認証

- リモート・ユーザーの認証

- SAMLの使用

- SSO (シングル・サインオン)の構成

- Microsoftのクライアントに対するシングル・サインオンの構成

- WebブラウザとHTTPクライアントでのシングル・サインオンの構成

- Kerberosの使用

- 複数の認証プロバイダの使用

- パスワード作成ルールの構成

- ユーザーとグループの管理

- JASPIC (Java Authentication SPI for Containers)の使用

SSLの構成

- SSLの設定:主な手順

- IDおよび信頼の構成

- キーストアの作成: サンプル

- X.509証明書失効チェック

認可の構成

- ロールおよびポリシーによるWebLogicリソースの保護

- 認可プロバイダの構成

- 複数の認可プロバイダの使用

- JAAS認可の使用

- ロール・マッピング・プロバイダの構成

- JACC (Java Authorization Contract Containers)の使用

セキュリティ・レルムについてもっとよく知る

- セキュリティ・レルムの概要

- ユーザー

- グループ

- セキュリティ・ロール

- セキュリティ・ポリシー

- セキュリティ・プロバイダ

セキュリティを目的としたアプリケーションのプログラミング

- WebLogic Serverのセキュリティのプログラミング

- リソース・アダプタ・セキュリティの構成

- WebLogic Webサービス・セキュリティのトピック

ベスト・プラクティス

- 本番環境の保護

11 WebLogic Server Webサービス

この章では、WebLogic Server Webサービスについて紹介します。

この章の内容は以下のとおりです。

- Webサービスの概要

- Webサービスの構造

- Webサービスの標準

- Webサービスのためのロードマップ

Webサービスの概要

Webサービスは、企業のイントラネットまたはインターネット上で記述したり、パブリッシュしたり、呼び出したりすることができる自己完結型のアプリケーションです。Webサービスは、Extensible Markup Language (XML)やHTTPなどの標準のWebプロトコルを使用してアクセスされるので、Web上の(通常はXMLとHTTPをすでに理解している)多様な異種アプリケーションは、自動的にWebサービスにアクセスし、お互いと通信できます。

Webサービスの主な利点は、次のとおりです。

- 多様なハードウェアおよびソフトウェア・プラットフォームにわたる分散型アプリケーション間の相互運用性

- Webプロトコルを使用したファイアウォールによる、アプリケーションへの容易で幅広いアクセス

- 異種分散型アプリケーションの開発を容易にするクロス・プラットフォーム、クロス言語データ・モデル(XML)

Webサービスの構造

Webサービスは、以下の3つの要素で特徴付けられます。

- その機能(エクスポーズするビジネス機能)

- アクセスする方法(エクスポーズされた機能を利用するために必要なパブリッシュ済インタフェースのセット)

- 存在する場所(その機能をエクスポーズするWebサイト)

Webサービスにできること(つまり、サービスに実装されている機能)は、WSDL (Webサービス記述言語)という標準XMLボキャブラリで記述されています。たとえば、銀行業務Webサービスを作成し、口座をチェックしたり、取引明細書を印刷したり、入出金を処理したりできます。あらゆるコンシューマから呼び出すことのできるWSDLファイルにこれらの機能を記述して、銀行業務Webサービスへのアクセスを提供します。コンシューマ側では、どのWSDLファイルを呼び出すと何をできるかだけがわかっていればよく、Webサービスに関するそれ以上の情報は必要ありません。

Webサービス・クライアント(たとえば、デスクトップ・アプリケーション、Java Platform, Enterprise Editionポートレットなど)は、Webサービスに対してXMLドキュメント形式のリクエストを送信してWebサービスを呼び出します。Webサービスは、リクエストを処理し、その結果をXMLドキュメント形式でWebサービス・クライアントに返します。

Webサービス・クライアントは、SOAP (Simple Object Access Protocol)形式でメッセージを送信できます。SOAPはXML形式のメッセージング・フレームワークであり、分散環境で異種アプリケーション間での構造化された情報の交換を可能にします。次に、Webサービスはリクエストを処理し、SOAPメッセージを通してレスポンスを返します。

Representational State Transfer (REST) WebサービスやRESTフルWebサービスも開発できます。RESTは、SOAPのように追加のメッセージ層を使用することなく、HTTPなどの標準化されたインタフェースでデータを転送するためのシンプルなインタフェースを記述したものです。RESTは、一意のURIで特定できるステートレス・サービスをリソース(特定の情報のソース)とみなし、これらを作成するための設計ルールを提供します。クライアントは、メソッドの標準化された固定セットであるURIを使用してリソースにアクセスし、リソースの表現が返されます。クライアントは、新しいリソース表現ごとに状態を転送するよう指示されます。

セキュアなメッセージ交換を行うため、Webサービスは、サービスにアクセスするためのユーザー名やパスワードのような資格証明や、レスポンスを暗号化するための資格証明を必要とする場合があります。

Webサービスの標準

Webサービスは、次を含むXMLベースの企業標準のセットを必要とします。

- Webサービス・コンシューマとWebサービス・プロバイダの間での統一的な通信を可能にするデータ形式であるXML。

- ビジネス・トランザクションで使用するXMLボキャブラリを記述するフレームワークであるXMLスキーマ。

- Webサービスの実装において、構造化された情報を交換するためのプロトコルであるSOAP。

- Webサービスを記述するためのモデルを提供するXMLベースの言語であるWSDL。

- ポリシーを使用したWebサービスの機能、要件、一般的な特徴を記述するための柔軟性の高い拡張可能な文法を提供するフレームワークであるWS-Policy。

Webサービスのためのロードマップ

表11-1 Webサービスのためのロードマップ

主要なタスク

サブタスクと追加情報

WebLogic Webサービスについてもっとよく知る

- WebLogic Webサービスでサポートされる機能および基準

- Webサービス・タイプ

- JAX-WSとRESTful Webサービスから選択

- Webサービスのセキュリティ概念

(WebLogic Webサービス開発者向け)サンプルの使用

- サンプル・アプリケーションおよびサンプル・コード

- JAX-WS Webサービス・サンプル

- JAX-WS Webサービス・クライアント・サンプル

- 非同期JAX-WS Webサービス・クライアント・サンプル

- 信頼性のあるJAX-WS Webサービス・クライアント・サンプル

- JAX-RPC Webサービス・サンプル

- SAMLメッセージの保護

- JDeveloper Webサービスのチュートリアル(「Web Services」で検索)

- JDeveloperの手引き(「Web Services」で検索)

JAX-WSを使用したWebサービスの開発

- Javaからの開始

- WSDLからの開始

- JWSファイルのプログラミング

- JAXバインディングの使用

- Webサービスの呼出し

- Webサービスの非同期的な呼び出し

- Webサービスの信頼性のあるメッセージングの使用

- Webサービス永続性の管理

- Webサービスのメッセージ・バッファリングの構成

- クラスタ内のWebサービスの管理

- Webサービス原子性トランザクションの使用

- Webサービスのエンドポイントのパブリッシュ

- コールバックの使用

- MTOM/XOPを使用したバイナリ・データ伝送の最適化

- 動的プロキシ・クライアントの開発

- XMLカタログの使用

- SOAPを使用した例外処理

- SOAPメッセージ・ハンドラの作成と使用

- XMLメッセージ・レベルでの処理

- RESTful Webサービスのプログラミング

- HTTPセッションを使用したステートフルJAX-WS Webサービスのプログラミング

RESTful Webサービスの開発

- WebLogic ServerでのRESTful Webサービスの開発の標準サポート

- RESTful Webサービスの開発について

- ルート・リソース・クラスの定義

- ルート・リソース・クラスの相対URIの定義

- リクエストおよびレスポンスのメッセージ・タイプのカスタマイズ

- 高度なRESTful Webサービス・タスク

- RESTful Webサービス・クライアントの開発についてもっとよく知る

- クライアント・インスタンスの作成および構成

- Webリソース・インスタンスの作成

- リソースへのリクエストの送信

- リソースからのレスポンスの受信

- RESTful Webサービスの監視についてもっとよく知る

- WLSTを使用したRESTful Webサービスの監視

- Jersey JAX-RS RIのバージョンの更新

JAX-RPCを使用したWebサービスの開発

- Javaからの開始

- WSDLからの開始

- JWSファイルのプログラミング

- データ・バインディングについて

- Webサービスの呼出し

- Webサービスの非同期的な呼び出し

- Webサービスの信頼性のあるメッセージングの使用

- 会話形式のWebサービスの作成

- 非同期機能の併用

- バッファ付きWebサービスの作成

- コールバックによるクライアントへのイベントの通知

- 接続プロトコルとしてのJMSトランスポートの使用

- SOAPメッセージ・ハンドラの作成と使用

- Database Webサービスの使用

WebLogic Webサービスのデプロイと管理

- RESTful Webサービスのパッケージ化とデプロイ

- JAX-WS Webサービスの管理

- JAX-RPC Webサービスの管理

WebLogic Webサービスのセキュリティ

- WebLogic Webサービス・セキュリティ・ポリシーの使用

WebLogic Webサービスとの相互運用性

- Microsoft WCF/.NETとの相互運用性

- WebLogic Webサービス・セキュリティとOracle WSMセキュリティとの間での相互運用性

12 Enterprise JavaBeans (EJB)

この章では、Enterprise JavaBeansについて説明します。

この章の内容は以下のとおりです。

- EJBについて

- EJBの構造と環境

- EJBのクライアントと通信

- EJBのセキュリティ

- WebLogic ServerでのEJBのためのロードマップ

EJBについて

Enterprise JavaBeans (EJB) 3.1テクノロジは、コンポーネントベースのビジネス・アプリケーションの開発とデプロイメントで使用するサーバー側のコンポーネント・アーキテクチャです。EJBテクノロジを使用することで、Java EE 6テクノロジに基づいて、安全でポータブルな分散トランザクション・アプリケーションを迅速かつ容易に開発できます。

EJB 3.1の仕様では、プログラミングおよびパッケージ化モデルの変更が簡素化されています。前のバージョンのJavaインタフェースを使用する必要がなくなり、プレーンな従来型Javaオブジェクトに注釈付けし、EJBコンポーネントとして使用できるようになりました。EJBモジュールをWebアプリケーションの内部に直接配置できるようになり、簡素化はさらに進みました。これにより、WebコンポーネントおよびEJBコンポーネントを格納するアーカイブを作成して、それらをEARファイルに結合する必要はなくなりました。

WebLogic ServerでのEJBドキュメント

WebLogic ServerでEJBを使用する方法については、次を参照してください。

- EJB 3.1の新機能については、『Oracle WebLogic Server の新機能』のEnterprise Java Beans (EJB)に関する項を参照してください。

- WebLogic Serverでの3.1 EJBのプログラミング、パッケージ化およびデプロイについては、『Oracle WebLogic Server Enterprise JavaBeansのプログラミング』を参照してください。

- 分割ディレクトリ環境でのWebLogic Server EJBの整理および構築については、『Oracle WebLogic Serverアプリケーションの開発』を参照してください。

- 2.x EJBのプログラミングとパッケージ化については、『Oracle WebLogic Server Enterprise JavaBeansバージョン2.1のプログラミング』を参照してください。

その他のEJB情報

エンタープライズBeanの利点、エンタープライズBeanの種類、ライフサイクルなどのEJBの概念についての補足情報は、次のWebサイトを参照してください。

- Enterprise JavaBeans 3.1仕様(JSR-318)(http://jcp.org/en/jsr/summary?id=318)

- Java EE 6チュートリアル(http://download.oracle.com/javaee/6/tutorial/doc/bnblr.html)の「エンタープライズBeans」の章

- Java EE 6プラットフォームの概要: パート3 (EJB Technology, Even Easier to Use)(http://www.oracle.com/technetwork/articles/javaee/javaee6overview-part3-139660.html#ejbeasy)

セッションEJBによるビジネス・ロジックの実装

セッションBeanは、ビジネス・ロジックを実装します。セッションBeanインスタンスは、一度に1つのクライアントにサービスを提供します。セッションBeanには、ステートフル、ステートレス、およびシングルトンの3種類があります。

セッションBeanの種類およびそれらを使用するタイミングの詳細は、Java EE 6チュートリアル(http://download.oracle.com/javaee/6/tutorial/doc/gipjg.html)の「エンタープライズBeans」の章のセッションBeanの内容に関する項を参照してください。

ステートフル・セッションBean

ステートフル・セッションBeanは、特定のクライアントとの対話を反映する状態情報をメソッドやトランザクションをまたがって維持します。ステートフル・セッションBeanは、クライアントと他のエンタープライズBeanの対話を管理するか、ワークフローを管理できます。

例: 社員が個人のプロファイル情報を表示して更新できる、ある会社のWebサイトでは、ステートフル・セッションBeanを使用して様々な他のBeanを呼び出し、ユーザーがページ上で「データの表示」をクリックした後に以下のようなユーザーが必要とするサービスを提供できます。

- JSPからログイン・データを受け付け、そのログイン・データを検証する別のEJBを呼び出す

- 認可の確認をJSPに送信する

- 認可されたユーザーのプロファイル情報にアクセスするBeanを呼び出す

ステートレス・セッションBean

ステートレス・セッションBeanは、呼出し間でセッションやクライアントの状態の情報を格納しません。唯一格納されることのある状態はクライアントに固有のものではなく、キャッシュされたデータベース接続や別のEJBの参照などです。ステートレス・セッションBeanが状態を格納できるのは、長くてメソッド呼出しの期間だけです。メソッドが完了すると、状態情報は維持されません。

ステートレス・セッションBeanのインスタンスはすべて、任意のクライアントにサービスを提供できます - どのインスタンスも同等です。ステートレス・セッションBeanは、ステートフル・セッションBeanよりもパフォーマンスが優れています。その理由は、各ステートレス・セッションBeanが複数のクライアントをサポートできるからです(ただし一度に1つ)。ステートレス・セッションBeanのクライアントは、Webサービス・エンドポイントにできます。

例: 訪問者が問合せ先リンクをクリックして電子メール送信できるインターネット・アプリケーションでは、ステートレス・セッションBeanを使用して、JSPによってユーザーから収集された送信先と送信元の情報に基づいて電子メールを生成できます。

シングルトン・セッションBean

シングルトン・セッションBeanが提供する正式なプログラミング構成により、特定のJava仮想マシン(JVM)内のアプリケーションごとにセッションBeanがインスタンス化され、そのアプリケーションのライフサイクルに存在することが保証されます。シングルトンにより、エンタープライズBeanコンポーネントの複数のインスタンス間、またはアプリケーション内の複数のエンタープライズBeanコンポーネント間で、容易に状態を共有することができます。

シングルトン・セッションBeanはステートレス・セッションBeanと同様の機能を提供します。ただし、ステートレス・セッションBeanではそのプールでクライアント要求に応答するのに対して、シングルトン・セッションBeanはアプリケーションごとに1つしかありません。シングルトン・セッションBeanは、ステートレス・セッションBeanと同様に、Webサービス・エンドポイントを実装できます。シングルトン・セッションBeanではクライアントの呼出し間でその状態を保持しますが、サーバーのクラッシュまたは停止時にはその状態を保持する必要はありません。

例: 中央カウンタ・サービスを提供するインターネット・アプリケーション。ステートレス・シングルトンBeanは、Javaクライアントからコールされ、クライアントが複数回呼び出されると、カウントがそのたびに1ずつインクリメントされます。

メッセージドリブンBeanによる疎結合ビジネス・ロジックの実装

メッセージドリブンBeanは、リクエストに対するレスポンスが即時である必要のない疎結合(非同期)のビジネス・ロジックを実装します。メッセージドリブンBeanは、JMSキューまたトピックからメッセージを受信し、そのメッセージの内容に基づいてビジネス・ロジックを実行します。それは、EJBとJMSの間の非同期インタフェースです。

MDBインスタンスはそのライフサイクルを通じて、同時にではありませんが複数のクライアントからのメッセージを処理できます。特定のクライアントの状態は維持されません。メッセージドリブンBeanのインスタンスはすべて同じ機能であり、EJBコンテナはどのMDBインスタンスにもメッセージを割り当てることができます。コンテナは、それらのインスタンスをプールしてメッセージのストリームの並行処理を可能にします。

EJBコンテナは、必要に応じてBeanのインスタンスを作成し、JMSメッセージをインスタンスに渡すことによってメッセージドリブンBeanと直接対話します。コンテナは、デプロイメント時にBeanのインスタンスを作成し、メッセージのトラフィックに基づいて作動時にインスタンスを追加および削除します。

詳細は、『Oracle WebLogic ServerメッセージドリブンBeanのプログラミング』を参照してください。

例:顧客から注文を受けるプロセスがサプライヤへの発注プロセスを引き起こすオンライン・ショッピング・アプリケーションでは、サプライヤへの発注プロセスをメッセージドリブンBeanで実装できます。顧客の注文が必ずサプライヤへの発注につながる一方で、そのステップは疎結合になります。その理由は、顧客の注文を確定する前にサプライヤへの発注を生成する必要はないからです。関連するサプライヤへの注文が発行される前に顧客の注文が「蓄積」されるのは問題なく、有益なことです。

EJBの構造と環境

以下の節では、各Beanタイプで必須のクラス、EJB実行時環境、およびBeanの実行時の動作を管理するデプロイメント記述子ファイルについて簡単に説明します。

- EJBのコンポーネント

- EJBコンテナ

- 組込み可能なEJBコンテナ

- EJBメタデータ・アノテーション

- オプションのEJBデプロイメント記述子

EJBのコンポーネント

Beanの構造はBeanタイプによって異なります。表12-1では、各タイプのEJBを構成するクラスと、そのクラス・タイプの用途を定義しています。

注意:

EJB 2.1以前のAPIでは、ローカルおよびリモート・クライアントが、セッションBeanのローカルまたはリモート・ホームおよびローカルまたはリモート・コンポーネント・インタフェースによって、ステートフルまたはステートレス・セッションBeanにアクセスする必要がありました。これらのインタフェースはEJB 3.xでも使用し続けることができますが、EJB 2.1のリモートおよびローカル・クライアント・ビューは、シングルトン・セッションBeanではサポートされません。

詳細は、『Oracle WebLogic Server Enterprise JavaBeansバージョン2.1のプログラミング』のEJBのクラスとインタフェースの作成に関する項を参照してください。

表12-1 EJB 3.1のコンポーネント

EJBのコンポーネント

説明

ステートレス・セッション

ステートフル・セッション

シングルトン・セッション

MDB

リモート・ビジネス・インタフェース

リモート・ビジネス・インタフェースは、ビジネス・ロジックをリモート・クライアント(EJBとは別のアプリケーションで動作するクライアント)に公開します。リモート・クライアントから呼び出せるビジネス・メソッドを定義します。

はい

はい

はい

いいえ

ローカル・ビジネス・インタフェース

ローカル・ビジネス・インタフェースは、ビジネス・ロジックをローカル・クライアント(EJBと同じアプリケーションで動作しているクライアント)に公開します。ローカル・クライアントから呼び出せるビジネス・メソッドを定義します。

はい

はい

はい

いいえ

ローカル・インタフェースなし

インタフェースなしの場合、個別のビジネス・インタフェースを使用することなく、Beanクラスのパブリック・メソッドを公開する様々なローカル・ビューを表示できます。

はい

はい

はい

はい

Beanクラス

Beanクラスはビジネス・ロジックを実装します。

はい

はい

はい

はい

EJBコンテナ

EJBコンテナとは、アプリケーション・サーバーにデプロイされたBeanの実行時コンテナです。このコンテナはアプリケーション・サーバーの起動時に自動的に作成され、Beanと以下のような実行時サービスの間のインタフェースとして機能します。

- ライフサイクル管理

- コード生成

- セキュリティ

- トランザクション管理

- ロックと同時実行性制御

組込み可能なEJBコンテナ

従来のJava EEサーバーベースの実行とは異なり、組込み可能なものを使用することで、クライアント・コードとそれに対応するエンタープライズBeanを同じ仮想マシンおよびクラス・ローダー内で実行できます。これにより、テスト、オフライン処理(バッチ・ジョブなど)、およびデスクトップ・アプリケーションのEJBプログラミング・モデルの使用に対するサポートが向上します。

Java EEサーバーのエンタープライズBeanコンテナに存在するほとんどのサービスは、注入、コンテナ管理のトランザクションおよびセキュリティを含め、組込みエンタープライズBeanコンテナで使用できます。エンタープライズBeanコンポーネントは組込みでもJava EE環境でも同様に実行されるため、同じエンタープライズBeanをスタンドアロンおよびネットワーク・アプリケーションの両方で容易に再利用できます。

組込みEnterprise Beanコンテナの詳細は、『Oracle WebLogic Server Enterprise JavaBeansのプログラミング』のOracle WebLogic Serverでの組込みEJBコンテナの使用方法に関する項を参照してください。

EJBメタデータ・アノテーション

WebLogic Server EJB 3.1プログラミング・モデルでは、Java EE 6メタデータ・アノテーション機能を使用して、アノテーション付きEJB 3.1 Beanファイルを作成します。次に、WebLogicコンパイル・ツールweblogic.appc (またはこれと同等のAntタスクwlappc)を使用してBeanファイルをJavaクラス・ファイルにコンパイルし、必須のEJBインタフェースやオプションのデプロイメント記述子など、関連するEJBアーティファクトを生成します。

詳細は、『Oracle WebLogic Server Enterprise JavaBeansのプログラミング』のアノテーション付きEJBクラスのプログラミングに関する項を参照してください。

オプションのEJBデプロイメント記述子

EJB 3.0以降では、EJBデプロイメント記述子ファイル(ejb-jar.xmlなど)を作成する必要がなくなりました。ただし、必要に応じて、引き続きXMLデプロイメント記述子を使用することはできます。競合がある場合、デプロイメント記述子の値がアノテーションの値をオーバーライドします。

EJB実装で引き続きデプロイメント記述子を使用する場合は、『Oracle WebLogic Server Enterprise JavaBeansバージョン2.1のプログラミング』のEJBデプロイメント記述子に関する項を参照してください。

WebLogic ServerのEJB 2.xには、次の3つのデプロイメント記述子があります。

- ejb-jar.xml: 標準Java EEデプロイメント記述子です。Beanはすべてejb-jar.xmlで指定する必要があります。ejb-jar.xmlでは、一緒にデプロイされる複数のBeanを指定できます。

- weblogic-ejb-jar.xml: クラスタリング、キャッシング、トランザクションといったWebLogic Serverの機能と関連する要素を格納するWebLogic Server固有のデプロイメント記述子。このファイルは、BeanがWebLogic Server固有の機能を利用する場合は必須です。ejb-jar.xmlと同じように、weblogic-ejb-jar.xmlでは一緒にデプロイされる複数のBeanを指定できます。

- weblogic-cmp-jar.xml - エンティティBeanのコンテナ管理による永続性に関連する要素を格納するWebLogic Server固有のデプロイメント記述子。コンテナ管理による永続性を使用するエンティティBeanは、weblogic-cmp-jar.xmlファイルに指定する必要があります。

WebLogic Server EJB 2.xデプロイメント記述子の詳細は、『Oracle WebLogic Server Enterprise JavaBeansバージョン2.1のプログラミング』のデプロイメント記述子スキーマおよび文書型定義リファレンスに関する項を参照してください。

EJBのクライアントと通信

EJBは、サーブレット、Javaクライアント・アプリケーション、他のEJB、Webサービス、非Javaクライアントなどのサーバー側またはクライアント側オブジェクトからアクセスできます。EJBのクライアントは、アプリケーションが同じか別かに関係なく同じ方法でEJBにアクセスします。WebLogic Serverは、Beanにローカル・インタフェースしかない場合を除いて、リモートで機能できるEJBのホーム・インタフェースおよびビジネス・インタフェースの実装を自動的に作成します。

EJBへのアクセス

クライアントは、インタフェースなしのビューまたはビジネス・インタフェースを介してエンタープライズBeanにアクセスします。エンタープライズBeanのインタフェースなしのビューでは、エンタープライズBean実装クラスのパブリック・メソッドをクライアントに公開します。エンタープライズBeanのインタフェースなしのビューを使用しているクライアントは、エンタープライズBean実装クラスまたはその実装クラスの任意のスーパークラスの任意のパブリック・メソッドを呼び出すことができます。ビジネス・インタフェースは、エンタープライズBeanのビジネス・メソッドを含む標準のJavaプログラミング言語インタフェースです。

エンタープライズBeanのクライアントは、エンタープライズBeanのインスタンスへの参照を取得します。そのためには、Javaプログラミング言語のアノテーションで依存関係インジェクションを使用するか、エンタープライズBeanインスタンスを検索するJNDI構文を使用してJNDIルックアップを実行します。

エンタープライズBeanインタフェースを取得する最も簡単な方法は、依存関係インジェクションです。Java EEサーバー管理対象の環境、JavaServer Faces Webアプリケーション、JAX-RS Webサービス、その他のエンタープライズBean、またはJava EEアプリケーション・クライアントの中で実行されるクライアントは、javax.ejb.EJBアノテーションを使用した依存関係インジェクションをサポートします。

Java SEアプリケーションなど、Java EEサーバー管理対象の環境外で実行されるアプリケーションは、明示的ルックアップを実行する必要があります。JNDIでは、Java EEコンポーネントを識別して明示的ルックアップを単純化するグローバル構文をサポートします。詳細は、『Oracle WebLogic Server Enterprise JavaBeansのプログラミング』のEJBクライアントへのアクセスのプログラミングに関する項を参照してください。

ネットワークのオーバーヘッドのため、Beanにはリモート・クライアントからアクセスするよりも同じマシン上のクライアントからアクセスする方が効率的であり、クライアントが同じアプリケーションにあればさらに効率的です。

クライアントによるEJBへのアクセスのプログラミングの詳細は、Java EE 6チュートリアル(http://docs.oracle.com/javaee/6/tutorial/doc/gipjf.html)の「エンタープライズBean」のエンタープライズBeanへのアクセスに関する項を参照してください。

EJBの通信

WebLogic Server EJBは、以下のプロトコルを使用します。

- T3 - リモート・オブジェクトとの通信に使用します。T3は、Remote Method Invocation (RMI)プロトコルを実装するWebLogic独自のリモート・ネットワーク・プロトコルです。

- RMI - リモート・オブジェクトとの通信に使用します。RMIを使用すると、アプリケーションはネットワークの他のどこかにあるオブジェクトの参照を取得し、同じJVMでクライアントと共存しているかのようにそのオブジェクトのメソッドをクライアントの仮想マシンからローカルで呼び出すことができます。
リモート・インタフェースのあるEJBはRMIオブジェクトです。EJBのリモート・インタフェースは、java.rmi.remoteを拡張します。WebLogic RMIの詳細は、『Oracle WebLogic Server RMIのプログラミング』を参照してください。

- HTTP - EJBは、java.net.URLリソース接続ファクトリを使用してWebLogic Server環境外のWebサーバーとのHTTP接続を取得できます。詳細は、『Oracle WebLogic Server Enterprise JavaBeansバージョン2.1のプログラミング』のURLにリクエストを送信するためのEJBの構成に関する項を参照してください。

EJBが使用するネットワーク接続の属性は、EJBをWebLogic Serverカスタム・ネットワーク・チャネルにバインドすることによって指定できます。詳細は、『Oracle WebLogic Serverサーバー環境の構成』のネットワーク・リソースの構成に関する項を参照してください。

EJBのセキュリティ

デフォルトでは、EJBのパブリック・メソッドはどのユーザーでも呼び出すことができます。EJBへのアクセスを制限するには、セキュリティ・アノテーションを使用して、ロールによってメソッドの呼び出せる範囲(すべてのメソッドかメソッドのサブセットか)を指定できます。詳細は、『Oracle WebLogic Server Enterprise JavaBeansのプログラミング』のEJBのアクセス・セキュリティに関する項を参照してください。

また、セキュリティ・ロールを作成し、ロールにユーザーをマッピングするには、WebLogic Server管理コンソールでセキュリティ・レルムを更新します。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのセキュリティ・ロールの管理に関する項を参照してください。

セキュリティとEJBの詳細は、以下を参照してください。

- 『Oracle WebLogic Serverセキュリティの理解』のセキュリティの基礎に関する項に、認証、認可など、セキュリティ関連の基礎的な情報があります。

- EJBの認証と認可を構成する手順については、『Oracle WebLogic Serverセキュリティのプログラミング』のEnterprise JavaBeans (EJB)のセキュリティ対策に関する項を参照してください。

- 『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』に、管理コンソールを使用してEJBの認証と認可を構成する手順が含まれています。

WebLogic ServerでのEJBのためのロードマップ

表12-2 WebLogic ServerでのEJBのためのロードマップ

主要なタスク

サブタスクと追加情報

EJB 3.1について

- バージョン3.0と3.1との変更点

- EJB 3.1の新機能

- WebLogic ServerのEJB 3.0の付加価値機能

単純なEJBサンプル

- 単純なステートレスEJBのサンプル

- 単純なステートフルEJBのサンプル

- インターセプタ・クラスのサンプル

- WebLogic Serverにパッケージ化されたEJB 3.1のサンプル

- セッションBeanからエンティティを呼び出すサンプル

反復的EJB開発

- EJB開発プロセスの概要

- ソース・ディレクトリの作成

- EJBクライアントへのアクセスのプログラミング

- トランザクションのプログラミングと構成

- EJBインタフェースのプログラミング

- EJBタイマー・サービスのプログラミング

- アノテーション付きEJBクラスのプログラミング

- 省略可能なインターセプタのプログラミング

- Javaソース・コードのコンパイル

- デプロイメント記述子の作成と編集(オプション)

- EJBのパッケージ化

- EJBのデプロイ

アノテーション付きEJBクラスのプログラミング

- メタデータ・アノテーションとEJB Beanファイルの概要

- Beanファイルのプログラミング: 要件および2.xからの変更点

- Beanファイルのプログラミング: 一般的な手順

- メタデータ・アノテーションの機能別一覧

EJBデプロイメントのガイドライン

- EJBをデプロイする前に

- デプロイメント・タスクの概要と実行

- EJBデプロイメントのガイドライン

Oracle WebLogic Serverでの組込みEJBコンテナの使用方法

- 組込み可能なEJBコンテナの概要

- 組込みEJBコンテナでサポートされるEJB 3.1 Liteの機能

Oracle WebLogic Serverでの永続性プロバイダの構成

- Oracle TopLinkの概要

- 永続性プロバイダの指定

- Oracle WebLogic ServerでのOracle TopLinkの使用方法

- Oracle WebLogic ServerでのOracle Kodoの使用方法

- Oracle WebLogic ServerでのOpenJPAの最新バージョンの使用方法

リファレンス

- EJBメタデータ・アノテーション・リファレンス

Oracle WebLogic ServerでのOracle Kodoの使用方法

注: Oracle TopLink (JPA 2.0永続性プロバイダ)は、前のリリースのデフォルト・プロバイダのKodoに取ってかわり、現在デフォルトのJPAプロバイダになっています。詳細は、「Oracle WebLogic Serverでの永続性プロバイダの構成」を参照してください。

- Oracle Kodoの概要

- Oracle Kodoアプリケーションの作成

- バージョンの異なるOracle Kodoの使用

- 永続性の構成

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

- Oracle Kodoアプリケーションの構成

- Kodo永続性構成スキーマ・リファレンス

EJB 2.xについて

- Oracle WebLogic Server Enterprise JavaBeansバージョン2.1のプログラミング

13 監視、診断およびトラブルシューティング

この章では、WebLogic Serverにおける監視、診断およびトラブルシューティングについて説明します。

この章の内容は以下のとおりです。

- WebLogic Server診断フレームワーク

- ロギング・サービス

- SNMPサポート

- カスタムJMXアプリケーション

- Java EE管理API

- WebLogic Serverにおける監視、診断およびトラブルシューティングのためのロードマップ

WebLogic Server診断フレームワーク

WebLogic診断フレームワーク(WLDF)とは、WebLogic Serverのプロセス内で実行され標準的なサーバーのライフサイクルに参加する、一連のサービスを定義および実装するモニターおよび診断フレームワークです。WLDFを使用すると、実行中のサーバーおよびそのコンテナ内にデプロイされているアプリケーションによって生成された、診断データを作成、収集、分析、アーカイブし、それらのデータに対するアクセスを行うことができます。。このデータを基に、サーバーおよびアプリケーションの実行時パフォーマンスを把握できます。また、フォルト発生時に、このデータを使用して、フォルトを隔離および診断できます。

WLDFには、以下のようなデータの収集および分析用コンポーネントが含まれています。

- WebLogic Serverインストール・プログラムで利用可能なOracle JRockitのバージョンには、パフォーマンス監視およびプロファイリング・ツールであるJRockitフライト・レコーダ(JFR)と呼ばれるコンポーネントが含まれています。WebLogic Serverは、JFRとの固有の統合ポイントを提供します。

- WebLogic Serverイベントは、ランタイムまたはインシデント後の解析を行うための共有データ・セットに含めるようにフライト・レコーダに伝播されます。

- フライト記録のデータもWLDF診断イメージ・キャプチャに含まれるため、WLDFの監視ルールに基づいてフライト記録のスナップショットをキャプチャできます。この一連の機能により、実行中のJVMコンポーネントとFusion Middlewareコンポーネントの両方について、単一のビューで実行時システム情報をキャプチャおよび分析できます。

- 診断イメージ・キャプチャ - 障害発生後の分析に使用できる診断スナップショットをサーバーから作成します。診断イメージ・キャプチャには、JRockitフライト・レコーダ・データが含まれていて、それが使用可能である場合、JRockit Mission Controlで表示できます。

- アーカイバ - サーバー・インスタンスおよびアプリケーションから、データ・イベント、ログ・レコード、およびメトリックをキャプチャし、永続化します。

- インストゥルメンテーション - WebLogic Serverインスタンスおよびその上で実行されているアプリケーションに診断コードを追加し、コード内の指定された場所で診断アクションを実行します。インストゥルメンテーション・コンポーネントは、システム内のリクエストの流れを追跡できるように、診断コンテキストをリクエストに関連付けるための手段を提供します。WebLogic Server管理コンソールには、アプリケーションにおけるパフォーマンスの問題の識別に役に立つツールとして機能しているWLDFインストゥルメンテーション機能から取得したメソッド・パフォーマンス情報のリアルタイムおよび履歴ビューを表示する「リクエスト・パフォーマンス」ページが含まれています。

- ハーベスタ - WebLogic Server MBeanやカスタムMBeanなどのランタイムMBeanからメトリックをキャプチャします。メトリックはアーカイブして、履歴データを参照するために後でアクセスできます。

- 監視および通知 - サーバーおよびアプリケーションの状態をモニターし、監視の中で設定されている条件に基づいて通知を送信する手段を提供します。

- 監視ダッシュボードでは、サーバーとサーバー上で実行されているアプリケーションの診断データをグラフで表示できるビューとツールが提供されます。診断データを生成、取得、および存続させるための基になる機能は、WebLogic診断フレームワークによって提供されています。また、監視ダッシュボードでは、そのデータをチャートとグラフで表示するために追加ツールが提供されます。
監視ダッシュボードにより表示される診断データでは、測定に役立つ数値またはブール値を持つランタイムMBean属性の現在値または系時的に変更した値が表示されます。これらの値は、監視ダッシュボードでメトリックと呼ばれ、ドメイン内の1つ以上のサーバーの1つ以上のランタイムMBeanインスタンスから送信されます。

WLDFは、診断データに対する動的なアクセスと制御を可能にする標準化された一連のアプリケーション・プログラミング・インタフェース(API)、ならびにサーバーに関する可視性をもたらす改良されたモニターを実現します。独立系ソフトウェア・ベンダー(ISV)は、カスタム・モニタリングとWLDFとの統合に使用される診断ツールの開発にこれらのAPIを使用できます。

WLDFにより、標準インタフェースを通じてサーバー・データへの動的なアクセスが可能となり、特定の時点にアクセスされたデータを、サーバーの停止および再起動を行うことなく変更できます。

ロギング・サービス

WebLogicロギング・サービスには、ログ・メッセージの作成、表示、フィルタ、およびリスニング機能があります。ログ・メッセージは、WebLogic Serverインスタンス、サブシステム、およびWebLogic ServerまたはクライアントJVM上で実行されるJava EEアプリケーションによって生成されます。WebLogic Serverサブシステムは、ロギング・サービスを使用して、新しいアプリケーションのデプロイメント、1つまたは複数のサブシステムの障害などのイベントに関する情報を提供します。サーバー・インスタンスは、それを使用してサーバーのステータスを通知したり、特定のイベントに応答したりします。たとえば、WebLogicロギング・サービスを使用すると、エラー状態を報告したり、特定のサブシステムからログ・メッセージをリスニングしたりすることが可能です。

デフォルトでは、WebLogicロギング・サービスはJava Logging APIに基づいた実装を使用しています。ただし、WebLogicロギング・サービスでLog4jを再構成できます。また、WebLogic Serverでは、サーバー・ロギング・ブリッジも導入されています。サーバー・ロギング・ブリッジは、現在JavaロギングまたはLog4Jロギングを使用してログ・メッセージをWebLogicロギング・サービスにリダイレクトさせているアプリケーションに対して、軽量のメカニズムを提供しています。アプリケーションは既存の構成のままでサーバー・ロギング・ブリッジを使用できます。コードを変更したり、WebLogicロギングAPIをプログラムで使用する必要はありません。

SNMPサポート

SNMPでは、管理対象リソースの情報に対するリクエストが、マネージャからエージェントに送信されます。エージェントはリクエストされたデータを収集し、レスポンスを返します。また、管理対象リソースに対する定義済みのしきい値または条件を検出したときに、非請求レポート(通知)をマネージャに発行するように、エージェントを構成することもできます。

特定の管理対象リソースのデータをリクエストするには、マネージャがリソースを一意に識別できる必要があります。SNMPでは、各タイプの管理対象リソースは、OID (一意のオブジェクト識別子)が指定された管理対象オブジェクトとして、MIB (管理情報ベース)内に記述されます。個々の組織は、特定の管理対象オブジェクトをMIBモジュールに定義します。特定の管理対象リソースについて通信するには、マネージャとエージェントが両方とも、同じMIBモジュールにアクセスできる必要があります。

カスタムJMXアプリケーション

カスタム管理システムをWebLogic Server管理システムと統合するために、WebLogic Serverには標準ベースのインタフェースが用意されています。これらのインタフェースは、JMX (Java Management Extensions)仕様に完全に準拠しています。ソフトウェア・ベンダーはこれらのインタフェースを使用して、WebLogic Server MBeanをモニターし、WebLogic Serverドメインの構成を変更し、ドメイン内のすべてのサーバー・インスタンスに対するこれらの変更の配布(アクティブ化)をモニターすることができます。JMXクライアントはOracle独自のクラスを使用しなくても、すべてのWebLogic Server管理機能を実行できますが、リモートJMXクライアントではWebLogic Serverプロトコル(T3など)を使用してWebLogic Serverインスタンスに接続することをお薦めします。

Java EE管理API

Java EE管理仕様には、Java EE Webアプリケーション・サーバーおよびそのリソースの実行時状態をモニターおよび管理するための標準データ・モデルが記述されています。また、Java EE MEJB(Management EJB)コンポーネントによるモデルの標準マッピングも含まれています。

Java EE管理API群を使用すると、ソフトウェア開発者は、JDBC接続プールやデプロイされているアプリケーションなどのリソースをそれ1つで検出して参照できるJavaプログラムをJava EE Webアプリケーション・サーバー上に作成できます。このAPI群はJava EEの管理仕様の一部。Java EEの管理仕様では、すべてのJava EE Webアプリケーション・サーバーは標準データ・モデルでリソースを記述する必要があります。

WebLogic Serverにおける監視、診断およびトラブルシューティングのためのロードマップ

表13-1 WebLogic Serverにおける監視、診断およびトラブルシューティングのためのロードマップ

主要なタスク

サブタスクと追加情報

WLDFコンポーネントについてもっとよく知る

- データの作成、収集、およびインストゥルメンテーション

- アーカイブ

- 監視と通知

- データ・アクセサ

- 監視ダッシュボードおよびリクエスト・パフォーマンス・ページ

- 診断イメージ・キャプチャ

- WLDF構成について

- Oracle JRockitフライト・レコーダと連携したWLDFの使用

WebLogicロギング・サービスについてもっとよく知る

- アプリケーション・ロギングのためのWebLogicロギング・サービスの使用方法

- WebLogic Serverでのメッセージ・カタログの使用方法

- ロギング・コンポーネントと環境

- 用語

- ロギング・プロセスの概要

- WebLogicロギング・サービスへのJavaロギングまたはLog4jの統合のベスト・プラクティス

- サーバー・ログ・ファイルとドメイン・ログ・ファイル

- サーバー・ログとサブシステム・ログ

- ログ・メッセージのフォーマット

- メッセージの属性

- メッセージの重大度

- WebLogicロギング・サービスの表示

- WebLogicロギング・サービスの構成

- WebLogic Serverログ・メッセージのフィルタ処理

- メッセージのサブスクライブ

- サーバー・ロギング・ブリッジの使用方法

監視ダッシュボードの使用

- 監視ダッシュボードのインタフェースについて

- メトリックの収集と表示方法について

- チャートの構成要素

WebLogic ServerでのSNMPの使用

- WebLogic Server SNMPエージェント

- SNMPのセキュリティ

- WebLogic Server用のMIBモジュール

- カスタムMBeanの監視

- WebLogic Serverの通知

- SNMPプロキシ

- WebLogic SNMPコマンドライン・ユーティリティ

WebLogic Serverの管理を目的としたJMXアプリケーションの開発

- JMXによるカスタム管理ユーティリティの開発

- JMXによる管理の容易なアプリケーションの開発

- WebLogicデプロイメントのプログラミング

Java EE管理APIについてもっとよく知る

- JMOの階層

- JMOのオブジェクト名

- JMOの任意指定の機能

- JMOへのアクセス

- WebLogic ServerでのMEJBへのアクセス

- WebLogic Server拡張

14 サンプル・アプリケーションおよびサンプル・コード

この章では、WebLogic Serverの学習および操作の様々な方法を紹介するWebLogic Serverコードのサンプルやサンプル・アプリケーションについて説明します。カスタム・インストールでサーバー・サンプルを選択すると、これらのサンプルやサンプル・アプリケーションがインストールされます。

この章の内容は以下のとおりです。

- Java EE 6のサンプル

- 追加のAPIサンプル

- Avitek Medical Records

- Derbyオープンソース・データベース

WebLogic Serverでは、任意でAPIコード・サンプルをWL_HOME\samples\server\examples\src\examplesにインストールされます。WL_HOMEはWebLogic Serverインストール先の最上位ディレクトリを示します。サンプルは、「スタート」メニューから利用できます。Linuxや他のプラットフォームでは、WL_HOME/samples/domains/wl_server directoryディレクトリからサンプル・サーバーを起動できます。

サンプル・ドメイン用の管理ユーザー名/パスワードは、weblogic/welcome1です。

注意:

weblogicユーザーのパスワードを変更した場合は、WebLogic Serverの起動が失敗する可能性があります。回避策および詳細は、『Oracle WebLogic Serverサーバーの起動と停止の管理』のユーザーweblogicに関する制限事項に関する項を参照してください。

Java EE 6のサンプル

Oracle WebLogic Serverは、Java Platform, Enterprise Edition (Java EE) 6仕様を完全サポートしています。Java EE 6の例によって、Java EE 6 APIとOracle WebLogic Server専用機能を実装する方法を詳しく解説します。例は次のカテゴリに分類されます。

- Beanの検証: JPAエンティティ、Java SEからのJPA、およびJSF管理対象BeanによるBean検証機能を使用します。

- CDI (Context and Dependency Injection): 型安全な依存関係インジェクション、インターセプタ、およびプロデューサを使用してCDIを紹介します。

- データ・ソース: @DataSourceDefinitionアノテーションを使用します。

- EJB 3.1: 非同期メソッド、カレンダ・ベース・タイマー、WARファイルにおける簡単なプログラミング・モデルとパッケージ化、ポータブル・グローバルJNDI名、シングルトン・セッションBeanを使用します。

- RESTful Webサービス(JAX-RS) 1.1用Java API: JAX-RSを使用してRESTful Webサービスを構築します。

- Java EE Connector Architecture 1.6: Java EE Connector Architectureを使用し、株式取引アプリケーションを使用する2つのアプリケーションを同時に接続します。

- JPA 2.0: JPA Criteria Query APIと@ElementCollectionマッピング型を使用します。

- JSF 2.0: AjaxのWebアプリケーションへの組込み、ブックマーク可能なWebアプリケーションの作成、Faceletsとテンプレートの使用を行います。

- サーブレット3.0: サーブレット、フィルタ、リスナーに対するアノテーションの使用、マルチパート・ファイルを使用したファイル・アップロードの処理、非同期サーブレットとリクエストの処理、プログラミングの安全性、およびサーブレットWebフラグメンツの使用を行います。

追加のAPIサンプル

これらの例によって、追加のJava EE APIとOracle WebLogic Server専用機能を実装する方法を詳しく解説します。例は次のカテゴリに分類されます。

- データベース接続: DataSource、MultiDataSourceおよびRowsetを使用します。

- EJB: ステートレスEJB、ステートフルEJB、エンティティEJB、メッセージドリブンEJB、その他EJBを作成します。

- 国際化: シンプル・メッセージ・カタログを使用したアプリケーションを国際化します。

- メッセージング: JMSトピック、JMSキュー、メッセージドリブンBeanを使用します。

- リソース・アダプタ: エンティティEJBを使用してJava EEコネクタ・アーキテクチャのリソース・アダプタと対話します。

- セキュリティ: Java認証・許可サービスのSAMLおよびアウトバウンドと双方向SSLを使用します。

- トランザクション: JTAを使用した分散トランザクションを実行します(トランザクションには、2つのXAリソースにわたる2フェーズ・コミット・プロトコルを使用します)。

- Webアプリケーション: 簡単なサーブレットおよびJSPを作成したり、HTTPパブリッシュ/サブスクライブ・サーバーを使用したり、様々なことを行います。

- Webサービス: JWSアノテーションを使用した様々なWebサービスを作成します。

- XML: StAX APIおよびXMLBeanを使用します。

- クラスタ: EJBをクラスタリングし、HTTPセッション状態レプリケーションを使用します。

- WebLogic Scripting Tool: WebLogic Scripting Tool (WLST)を使用して、実行中WebLogic管理サーバーを構成および管理します。

- 分割開発: WebLogic分割開発ディレクトリ構造を使用して、エンタープライズ・アプリケーションのビルド、パッケージ化、デプロイを行います。

- サービス・コンポーネント・アーキテクチャ: WebLogic SCA、軽量Spring 2.5(またはそれ以降)のコンテナを、主要な機能の多くを示すショッピング・カート・アプリケーションで使用します。

- Spring: Springにより簡略化された構成をSpringベースのWebアプリケーションで使用します。

Avitek Medical Records

Avitek Medical Record (MedRec)は、WebLogic ServerおよびJava EEの機能とベスト・プラクティスを例示する総合的な学習用サンプル・アプリケーションです。Server Exampleをインストールする場合は、Avitek Medical RecordはWindowsの「スタート」メニューから利用できます。Linuxおよびその他のプラットフォームでは、WL_HOME/samples/domains/medrec directoryディレクトリから起動できます。WL_HOMEはWebLogic Serverインストール先の最上位ディレクトリです。

サンプル・アプリケーションのMedRec(Spring)では、Spring 3.0.xアプリケーションの開発例を示します。

Medical Recordドメイン用のデフォルト管理ユーザー名およびパスワードは、それぞれweblogic/welcome1です。

Derbyオープンソース・データベース

Derbyは、JavaやJDBC、SQL標準に基づいたオープン・ソースのリレーショナル・データベース管理システムです。デモ用データベースとしてサンプル・アプリケーションやサンプル・コードで使用するために、WebLogic Serverにバンドルされています。Derbyの詳細は、http://db.apache.org/derbyを参照してください。

15 WebLogic Serverの互換性

Oracleでは、永続的データ、生成されるクラス、およびAPIの互換性について、現在のバージョンのWebLogic ServerとWebLogic Server 9.2以降の全バージョンの、バイナリおよびソース・レベルでの互換性をサポートしようと考えています。ただし、完全な互換性を維持できない場合もあります。そのような場合について、『Oracle WebLogic Serverアップグレード・ガイド』で詳しく説明しています。

Java EE 6の互換性

WebLogic Server 12c リリース1 (12.1.1)はJava EE 6と互換性があります。この互換性があるため、あるオペレーティング・システム・プラットフォームでJava EE 6に準拠したアプリケーションを開発し、そのアプリケーションを別のプラットフォームに本番環境としてデプロイできます。その際、Java EE 6アプリケーションのコードを変更する必要はありません。OracleはこのようなJava EE 6アプリケーションの移植に関する互換性をWebLogic Serverの1つのリリース・レベルの範囲内で保証しています。

生成されるクラスの互換性

1つの例外を除き、WebLogic Server 12c リリース1 (12.1.1)にアップグレードする場合、アプリケーションを再コンパイルしてクラスを新しく生成する必要はありません。

現在のバージョンのEJBGenユーティリティは、JDK 5.0以降メタデータ・アノテーション・スタイルの「EJBGen」タグのみを認識し、以前のJavadocスタイルのタグは認識しません。つまり、Javadocスタイルのタグを使用するソース・ファイルは、同等のアノテーションを使用するようにアップグレードしてから、更新されたバージョンのEJBGenを使用して再コンパイルする必要があります。

ドメイン内での互換性

- 同一の管理ドメイン内のWebLogic Serverインスタンスはすべて、メジャーおよびマイナー・バージョンが同じである必要があります。1つのドメイン内でサーバーのバージョンを混在させることはできません。WebLogic Serverリリース12.1.1から、最初の2桁がメジャー・バージョンを、3桁目がマイナー・バージョンを示します。ドメイン内のすべてのサーバーは、バージョン12.1.1にする必要があります。

- 管理ドメイン内のサーバー・インスタンスは、管理サーバーと管理対象サーバーのパッチ・セット・レベルが管理対象サーバーより高い場合、様々なパッチ・セット・レベルにできます。ドメイン自体は、一番古いバージョン番号のままにする必要があり(アップグレードは禁止)、新しいバージョンに追加された属性を構成に含めることはできません。

- クラスタ内のすべてのサーバー・インスタンスは同じパッチ・セット・レベルにある必要があります。たとえば、クラスタ内のすべてのサーバーはバージョン12.1.1.1にして、クラスタ内でバージョン12.1.1.1や12.1.1.2を混在させることはできません。

- クラスタまたはドメイン内のサーバー・インスタンスはハードウェアおよびオペレーティング・システムが「サポートされるシステム構成」ページ(http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html)にリストされている任意のハードウェアおよびオペレーティング・システム上で実行できます。ただし、クラスタ・サーバー・インスタンスが異なるハードウェアおよびオペレーティング システムで実行されている場合は、ロード・バランシングおよびパフォーマンスに影響がある可能性があります。

永続的データの互換性

WebLogic Server 9.xから12.1.1へ移動する場合は、構成ファイルに変更を加える必要があります。WebLogic Serverのバージョン9.0以降では、アップグレード・ツールによって、構成ファイルが自動的に変換されます。

APIの互換性

WebLogic Server 12c リリース1 (12.1.1)にデプロイされるWebLogic Server 9.x、10.0、10.3.xのアプリケーションは、変更しなくても動作します。ただし、仕様への準拠や不具合の修正を目的としてAPIの動作が変更されている場合があります。特定の状況では、これらの変更によってアプリケーションの動作が変わる可能性があります。

プロトコルの互換性

WebLogic Server 12c リリース1 (12.1.1)とWebLogic Server 9.x、10.0、10.3.xの間の相互運用性は、次のシナリオでサポートされています。

- WebLogic Server 9.x、10.0、10.3.xクライアントは、IIOP、T3、T3S、HTTPおよびHTTPSを使用してWebLogic Server 12.1.1サーバーがホストするRMIベースのアプリケーションを呼び出すことができます。JMSアプリケーションは、T3、T3S、HTTP、およびHTTPSを使用して呼び出すことができます。

- Weblogic Server 12.1.1クライアントは、IIOP、T3、T3S、HTTPおよびHTTPSを使用してWebLogic Server 9.x、10.0および10.3.xサーバーがホストするRMIベースのアプリケーションを呼び出すことができます。JMSアプリケーションは、T3、T3S、HTTP、およびHTTPSを使用して呼び出すことができます。

- WebLogic Server 12.1.1 Webサーバー・プラグインは、9.x、10.0および10.3.xの最新のパッチ・セット・リリースのサーバーにプロキシできます。

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