| ドキュメントのダウンロード | サイト マップ | Glossary | |
|
|||
| BEA ホーム | 製品 | dev2dev | support | askBEA |
|
|
|
|||||||
 |
| e-docs > WebLogic Server > WebLogic Server 7.0 および WebLogic Express の紹介 > WebLogic Server のサービス |
|
WebLogic Server 7.0 および WebLogic Express の紹介
|
以下の節では、WebLogic Server のサービスについて説明します。
WebLogic Server は、高度な Web 対応アプリケーションのためのプライマリ Web サーバとして使用することができます。J2EE Web アプリケーションとは、HTML または XML ページ、JavaServer Pages、サーブレット、Java クラス、アプレット、画像、マルチメディア ファイル、およびその他の種類のファイルの集まりです。
Web サーバとしての WebLogic Server の機能
Web アプリケーションは、Web サーバの Web コンテナ内で動作します。WebLogic Server 環境では、Web サーバは論理的なエンティティであり、クラスタ内の 1 つまたは複数の WebLogic Server 上でデプロイされます。
Web アプリケーション内のファイルは、ディレクトリ構造に格納されます。Java の jar ユーティリティを使用して 1 つの .war (Web アーカイブ) ファイルにまとめることもできます。一連の XML デプロイメント記述子では、アプリケーションのコンポーネント、およびセキュリティ設定などの実行時パラメータが定義されます。デプロイメント記述子を使用すると、Web アプリケーション コンポーネントの内容を変えることなく実行時の動作を変更でき、また同じアプリケーションを簡単に複数の Web サーバ上にデプロイできます。
Web サーバとしての WebLogic Server には、次のような機能がサポートされています。
この節では、これらの機能に関する WebLogic Server のサポートについて説明します。
WebLogic Server は、仮想ホスティングをサポートしています。 これにより、1 つの WebLogic Server インスタンスまたは WebLogic Server クラスタで複数の Web サイトをホストすることができます。論理上の Web サーバには、それぞれ独自のホスト名が付けられていますが、すべての Web サーバは、DNS で同じクラスタの IP アドレスにマップされます。クライアントが HTTP リクエストをクラスタ アドレスに送信すると、リクエストを提供する WebLogic Server が選択されます。Web サーバ名が HTTP リクエストのヘッダから抽出されて、仮想ホスト名がクライアント側から見て一定になるように、以降のクライアントとのやりとりの間維持されます。
複数の Web アプリケーションを WebLogic Server にデプロイできます。各 Web アプリケーションを仮想ホストにマップできます。
WebLogic Server は既存の Web サーバと統合できます。リクエストを WebLogic Server から別の Web サーバへプロキシしたり、WebLogic Server に付属のネイティブ プラグインを使用して、リクエストを別の Web サーバから WebLogic Server へプロキシしたりできます。BEA では、Apache Web Server、Netscape Enterprise Server、および Microsoft Internet Information Server 用のプラグインを提供しています。
クライアントと、一連の独立した WebLogic Server または WebLogic Server クラスタとの間でプロキシ Web サーバを使用すると、 Web リクエストのロードバランシングおよびフェイルオーバを実行できます。クライアントにとっては、それらは単に 1 つの Web サーバに見えます。
プロキシ サーバの背後に複数の WebLogic Server をセットアップすると、大量のリクエストに対応できます。プロキシ サーバはその背後の層にある複数のサーバ間にリクエストを分散することによってロードバランシングを行います。
プロキシ サーバは、WebLogic Server Web サーバでも、Apache、Netscape、または Microsoft Web サーバでもかまいません。WebLogic Server には、いくつかのプラットフォーム用のネイティブ コード プラグインが用意されています。 このプラグインを使用すると、これらのサードパーティ製 Web サーバは、リクエストを WebLogic Server にプロキシできます。
プロキシ サーバは、特定のタイプのリクエストをその背後にあるサーバにリダイレクトするようセットアップされています。たとえば、一般的な使い方として、静的な HTML ページへのリクエストはプロキシ サーバで処理し、サーブレットおよび JavaServer Pages へのリクエストはプロキシの背後の WebLogic Server クラスタにリダイレクトするようにプロキシ サーバをコンフィグレーションします。
Web クライアントがサーブレット セッションを開始すると、プロキシ サーバは、同じセッションの一部である後続のリクエストを別の WebLogic Server に送信できます。WebLogic Server では、クライアントのセッション ステートが利用可能のままであることを保証するために、セッション レプリケーションを提供しています。
セッション レプリケーションには、2 つのタイプがあります。
JDBC セッション レプリケーションでは、データベースへセッション データが記述されます。セッションが開始すると、プロキシ サーバが選択した任意の WebLogic Server は、データベースからセッション データを取得して、セッションを続行できます。
WebLogic Server クラスタをプロキシ サーバの背後にデプロイする場合に、サーブレット セッションをクラスタの選択したセカンダリ WebLogic Server にネットワーク経由でレプリケートすると、データベースにアクセスする必要がなくなります。インメモリ レプリケーションは、消費するリソースが少なく JDBC セッション レプリケーションよりも高速なため、WebLogic Server クラスタを使用する場合は、インメモリ レプリケーションが、サーブレットにフェイルオーバを提供するための最良の方法です。
WebLogic Server のセキュリティ コンポーネントはこのバージョンで全面的に設計が見直され、今までどのアプリケーション サーバ プラットフォームにも見られなかったレベルの柔軟性および制御性を実現しています。WebLogic Server における新しいセキュリティ アーキテクチャを利用すれば、アプリケーション開発者はセキュリティ実装の複雑な問題点に関与しなくてもよくなる一方、社内の開発スタッフやセキュリティ ベンダによって実装された最新のセキュリティ技術を利用できるようになります。
WebLogic Server のセキュリティ フレームワークは、WebLogic Server 環境用のセキュリティ サービスを開発するために使用される一連のサービス プロバイダ インタフェース (SPI) に基づいています。SPI が提供する機能には認証、認可、監査、公開鍵インフラストラクチャ (PKI)、証明書マッピング、およびユーザ プロファイルがあります。BEA が提供する既製のセキュリティ サービスをそのまま使用することも、あるいは SPI を使用して WebLogic Server 用のカスタム セキュリティ サービスを作成することもできます。カスタムのセキュリティ サービスは WebLogic Server 管理環境に統合でき、その場合、すべてのコンフィグレーションおよびモニタ作業を WebLogic Server Administration Console から実行できます。
WebLogic Server のオープンなセキュリティ アーキテクチャにより、既存のセキュリティ製品を利用しながら、一方で市場で展開されている新しいセキュリティ技術をいち早く採り入れることができます。また、採用するセキュリティ技術やセキュリティ ベンダを自由に選択することもできます。セキュリティ製品を適宜組み合わせて、完全なカスタム セキュリティ ソリューションを構築することができるのです。
WebLogic Server のセキュリティ アーキテクチャでは、可能な限り Java 標準に従うことによって、セキュリティの適用形態を統一し、その他の WebLogic Server コンポーネントにサービスとしてセキュリティを提供するフレームワークを形作っています。WebLogic Server では以下の Java セキュリティ標準がサポートされています。
図 2-1 は、WebLogic Security サービスの概略を示したものです。
WebLogic Server では新たに、すべての WebLogic Server リソースに適用可能な、ロールベースの動的な認可方式が導入されています。J2EE の宣言的セキュリティ モデルの制限によって制約を受けることはなくなりました。WebLogic Server 7.0 の Authorization サービスには、シンプルな自由記述形式のルールを作成するための資格エンジンが組み込まれており、動的なロール割り当ておよびアクセス権限の決定が可能になっています。資格エンジンにより、ビジネス ポリシー作成のタスクとアプリケーション作成のタスクが分離されるため、アプリケーション開発者は複雑なビジネス ポリシーを実装するアプリケーション コードを記述する必要がなくなりました。
すべてのユーザ プロファイルおよび資格データは、WebLogic Server 7.0 に統合されたシステム データ ストアに格納されます。システム データ ストアは、高速なデータ読み込みのために最適化されたスケーラブルなデータ ストアです。システム データ ストアに加えて、1 つまたは複数の LDAP ストアをコンフィグレーションし、複数のバックエンド リソースを統一した単一のプロファイリング システムを構築することができます。
WebLogic Security サービスの詳細については、『WebLogic Security の紹介』を参照してください。
WebLogic Server クラスタは、複数の WebLogic Server インスタンスのグループで、互いに連携して強力で信頼性の高い Web アプリケーション プラットフォームを提供します。クラスタは、クライアントにとっては 1 つのサーバに見えますが、実際には、1 つのものとして機能するサーバのグループです。クラスタには、スケーラビリティと可用性という、単一のサーバでは提供できない 2 つの主要なメリットがあります。
『WebLogic Server Clusters ユーザーズ ガイド』では、クラスタのプランニングとコンフィグレーションに関する詳細を説明しています。
WebLogic Server クラスタは、アプリケーション開発者からは見えないように、J2EE アプリケーションにスケーラビリティと高可用性を提供します。スケーラビリティのメリットは、WebLogic Server の単一のインスタンスまたは単一のコンピュータよりも、中間層の能力を拡大できることです。クラスタのメンバーシップにおける唯一の制限は、すべての WebLogic Server のインスタンスが IP マルチキャストで通信できなければならない点です。新しい WebLogic Server をクラスタに動的に追加して、能力を増大させることができます。
WebLogic Server クラスタはまた、複数サーバの冗長性を利用してクライアントを障害から保護することで高可用性を保証します。クラスタ内の複数のサーバで、同じサービスを提供できます。1 つのサーバで障害が発生しても、別のサーバが引き継ぎます。障害が発生したサーバから機能しているサーバへのフェイルオーバ機能によって、クライアントに対するアプリケーションの可用性が増大します。
WebLogic Server クラスタは、ネットワークにデプロイされた複数の WebLogic Server インスタンスから構成され、Domain Name Service (DNS)、JNDI ネーミング ツリーのレプリケーション、セッション データのレプリケーション、および WebLogic RMI を組み合わせて調整されます。
Web クライアントと WebLogic Server クラスタの間にある Web プロキシ サーバでは、サーブレットおよび JavaServer Pages 用にクラスタ化されたサービスを調整します。Web プロキシ サーバになるのは、別の WebLogic Server、または WebLogic Server 付属のプラグインと共に使用される Netscape、Microsoft、または Apache のサードパーティ製 Web サーバです。
Web クライアントは、プロキシ サーバにリクエストを転送することにより、WebLogic Server クラスタに接続します。Java RMI ベースのクライアントは、ネットワーク上で定義されたクラスタ アドレスを使用して、WebLogic Server クラスタに接続します。
サーバ サイド コードも、WebLogic クラスタの提供するロード バランシングおよびフェイルオーバ サービスの恩恵を受けています。J2EE アプリケーションでは、ほとんどのアプリケーション コードは中間層で動作するため、複数の WebLogic Server 間に分散されたサービスを使用できます。 たとえば、WebLogic Server「A」で動作中のサーブレットから、WebLogic Server「B」のエンタープライズ Bean を使用して、WebLogic Server「C」の JMS キューからのメッセージを読み込むことができます。
WebLogic Server クラスタをネットワークで定義する方法
WebLogic Server のサービスへは、DNS を介してアクセスします。DNS とは、インターネットを含むネットワーク上のリソースのための標準ネーミング サービスです。DNSは、170.0.20.1 などの IP アドレスを、「mycomputer.mydomain.com」または「www.bea.com」などの名前にマップします。各 WebLogic Server インスタンスは、ネットワーク上でユニークな IP アドレスで動作します。クライアントは、名前、および接続をリスンしているポートの番号を URL にエンコードすることにより、WebLogic Server に接続します。
たとえば、「onyx」という名前で、リスン ポートが 7701 に設定されたコンピュータ上で動作する WebLogic Server へは、「http://onyx:7701」という URLを使用して、Web ブラウザからアクセスできます。この接続が成功するには、ネットワーク上のネーム サーバで、ローカル ドメインの「onyx」という名前を解決する必要があります。送り先のサーバがインターネット上の別のドメインにある場合は、「http://onyx.bea.com:7701」のように、完全なドメイン名を入力する必要があります。
追加の DNS エントリでは、クラスタに参加するすべての WebLogic Server インスタンスの名前が 1 つのクラスタ名にマップされます。クライアントは、クラスタ名を使用するか、Web プロキシ サーバを介してリクエストをクラスタに転送することにより、クラスタに接続します。DNS は、クラスタ名のルックアップを実行すると、そのクラスタに属するすべてのサーバのリストを返します。クライアントは通常リストの最初のサーバを選択し、応答がなければ 2 番目のサーバを選択して、応答が得られるまでリスト内のサーバを順に選択してゆきます。
DNS は、リクエストをクラスタ内のサーバ間に分散する初期ロードバランシング サービスを提供します。各 DNS は、最終的に各サーバがリストを一巡するようにサーバのリストを 1 つずつローテーションして、クラスタ名のルックアップに応答します。
ネットワーク上で動作するインテリジェント ルータ、プロキシ サーバ、ファイアウォール、またはその他のソフトウェアは、DNS をオーバーライドし、マシンの負荷、ネットワーク トラフィック、またはその他の動的なロードバランシングの基準に基づいて、最初のサーバを選択します。
最初の WebLogic Server の接続は、クライアントに対してネーミング サービスを提供します。クライアントから要求されたサービスをルックアップし、WebLogic Server でコンフィグレーションされたロードバランシング アルゴリズムを使用して、要求を処理するサーバをクラスタから選択します。
クラスタ内の WebLogic Server は、特定のクラスの情報をクラスタ内のすべてのサーバにレプリケートするために、IP マルチキャストを使用して互いに通信します。クラスタ内の各サーバ インスタンスには、共通のマルチキャスト アドレスがコンフィグレーションされます。1 つのサーバがメッセージをクラスタのマルチキャスト アドレスに送信すると、すべてのサーバがそのメッセージを受信します。これは、サーバがポイント ツー ポイント メッセージを送信するよりも効率的です。ただし、この場合はクラスタ内のすべてのサーバがネットワーク上にあり、マルチ キャストをサポートしている必要があります。マルチキャストはインターネット上では動作しないため、クラスタがインターネットをまたがることはできません。
サービスによっては、クラスタはプライマリおよびセカンダリの WebLogic Server を選択します。 プライマリ WebLogic Server がリクエストの処理を開始してから使用できなくなると、セカンダリ サーバがリクエストの処理を停止せずに引き継ぐことができます。プライマリ サーバは、サーバ ツー サーバ接続を使用してセカンダリ サーバにステートをレプリケートします。
ほとんどのサービスは、クラスタ内の任意の数の WebLogic Server にデプロイできます。各サービスがデプロイされると、WebLogic Server は IP マルチキャストを使用して、サービスをクラスタワイドのネーミング ツリーに追加します。クラスタ内のいずれのサーバでも、クラスタワイドのネーミング ツリーでサービスをルックアップすることにより、サービスを提供する WebLogic Server を見つけることができます。複数のサーバがそのサービスを提供できる場合、クラスタはコンフィグレーション可能なロードバランシング アルゴリズムを使用してサーバを選択します。
ほとんどの WebLogic Server サービスはクラスタ化できます。したがって、これらのサービスはクラスタ内の任意の数のサーバにデプロイできます。クラスタは、サービスを提供する WebLogic Server インスタンスを選択します。サーバが選択され、ステートフル オブジェクトがサーバ上でインスタンス化されると、クライアントはサービスが終了するまでその WebLogic Server に「固定」 されます。固定されたオブジェクトのホストとなっている WebLogic Server で障害が発生した場合、クライアントはその障害を検出し、クラスタ内の他のサーバ上にもう 1 つのインスタンスを作成する必要があります。
より回復力のあるフェイルオーバを提供するために、WebLogic Server クラスタでは、特別に必要な場合以外は、オブジェクトをサーバに固定しません。場合により、クラスタはステートフル オブジェクトをバックアップ サーバにレプリケートして、サービスのフェイルオーバを有効にします。
Web サーバとしての WebLogic Serverで説明したように、Web アプリケーションはクラスタ化できます。サーブレット セッションがセカンダリ サーバにレプリケートされることにより、クラスタは透過的に障害から回復できます。
すべてのエンタープライズ JavaBean はクラスタ化できます。エンタープライズ JavaBean は、WebLogic Server クラスタ内の任意の数のサーバ上にデプロイできます。ただし、すべての EJB インスタンスがクラスタ化できるわけではありません。アプリケーションは、Bean がデプロイされている任意のサーバから EJB のホーム インタフェースを取得し、そのホーム インタフェースを使用して、Bean インスタンスを作成できます。ホーム インタフェースを提供するサーバに障害が発生すると、アプリケーションを停止せずに、別のサーバからホーム インタフェースを取得できます。
ステートレス セッション Bean や読み取り専用エンティティ Bean など、EJB インスタンスのタイプによっては、常にクラスタ化できるものもあります。ステートフル セッション Bean は、インメモリ レプリケーションを使用してフェイルオーバを提供することにより、クラスタ化できます。読み書き対応 エンティティ Bean は、Beanをインスタンス化するサーバに常に固定されます。読み書き対応エンティティ Bean のホストになっているサーバに障害が発生すると、安全な場合であればエンティティ Bean は自動的にフェイルオーバします。安全でない場合、フェイルオーバは次のトランザクションで発生し、クラスタ内の他のサーバ上にあるリモート スタブを使ってエンティティ Bean インスタンスを再作成します。
JDBC メタプールは、WebLogic Server クラスタ内の複数サーバにデプロイされた JDBC 接続プールにクラスタ化を提供します。クライアントがメタプールからの接続を要求すると、クラスタは接続を提供するサーバを選択し、ロードバランシングおよびサーバ障害に対する保護を可能にします。クライアントが接続を確立すると、JDBC ドライバで維持されているステートにより、クライアントをホストである WebLogic Server に固定する必要が生じます。
JMS オブジェクトは、クラスタ内のサーバ間に分散できます。接続ファクトリ (クライアントが送り先への接続を確立するために使用する) と送り先は、クラスタ内の複数のサーバにデプロイできます。送り先および接続ファクトリをクラスタ全体に分散すると、管理者は、JMS サービスの負荷を手動で調整できます。
WebLogic Server では、Administration Console またはコマンドライン インタフェースを使用して、ドメイン内のサーバの属性を設定することにより、管理を行います。Administration Console は Web ブラウザ アプリケーションです。Administration Console を使用すると、WebLogic Server サービスのコンフィグレーション、セキュリティの管理、アプリケーションのデプロイメント、およびサービスの動的なモニタを行えます。
Administration Console とコマンドライン インターフェースは、いずれも管理サーバに接続します。
管理サーバは、ドメイン内のすべての WebLogic Server をコンフィグレーションおよび管理するために使用する WebLogic Server です。ドメインには複数の WebLogic Server クラスタおよび複数の独立した WebLogic Server インスタンスが含まれます。ドメインに 1 つの WebLogic Server しか含まれない場合は、そのサーバが管理サーバになります。ドメインに複数の WebLogic Server インスタンスがある場合、最初に起動するインスタンスは管理サーバでなければなりません。
WebLogic Server Administration Console は Web ブラウザで動作します。クラスタや個々の WebLogic Server など、管理するドメインのコンポーネントが、左ペインのグラフィカル ツリーに表示されます。右ペインには、左ペインで選択したオブジェクトの詳細が表示されます。図 2-2 は、Administration Console の画面例です。
Administration Console を使用してサービスをコンフィグレーションするには、左ペインでアイテムを選択し、右ペインで [コンフィグレーション] タブを選択します。Administration Console の右ペインに、コンフィグレーション可能な属性が表示されます。表示される属性の詳細については、オンライン ヘルプを参照してください。
Administration Console を使用してサービスをコンフィグレーションする通常の手順では、サービスをコンフィグレーションしてから、そのサービスをデプロイする対象(WebLogic Server) を選択します。
デプロイされた各サービスでは実行時の統計が維持されます。統計は、Administration Console の右ペインの [モニタ] タブで表示できます。
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
