|
|
|
|
|
|
| | | |
WebLogic Server のサービス
以下の節では、WebLogic Server のサービスについて説明します。
Web サーバとしての 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 サーバの機能
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 は、セキュリティ レルムと呼ばれるサービスを通じてアプリケーションにセキュリティを提供します。セキュリティ レルムは、以下の 2 つのサービスへのアクセスを提供します。
注意: WebLogic Server は JNDI 認証メカニズムの代わりとして JAAS も提供しています。JAAS を使用するには、Java SDK バージョン 1.3 をインストールする必要があります。JAAS の認可コンポーネントは WebLogic Server では提供されていません。
認証
レルムは、ユーザおよびグループのストアへアクセスでき、ユーザが入力した資格（通常はパスワード）をセキュリティ ストア内のユーザ名および資格と照合することによって、ユーザを認証できます。 Web ブラウザは、Web クライアントが保護された WebLogic Server サービスにアクセスしようとしたときにユーザ名とパスワードを要求することによって、認証をサポートしています。他の WebLogic Server クライアントが、WebLogic Server との接続を確立する場合は、プログラム的にユーザ名と資格を提供します。
認可
WebLogic Server のサービスは、アクセス制御リスト（ACL）によって保護されています。ACL は、サービスへのアクセスを認可されたユーザおよびグループのリストです。ACL で一度ユーザが認可されたら、WebLogic Server は、 ACL をチェックしてから、ユーザにそのサービスへのアクセスを許可します。
代替レルムとカスタム レルム
セキュリティ レルムは、プラグイン可能です。WebLogic Server に付属の代替レルムであるデフォルトのファイル レルムを使用することも、独自のレルムを作成することもできます。デフォルトのファイル レルムは、ユーザ、グループ、および ACL を、暗号化されたファイルに格納します。そのファイルは、Administration Console で管理します。
WebLogic Server では、ユーザ、グループ、場合により ACLの外部ストアにアクセスする代替レルムが用意されています。代替レルムは、以下の外部のセキュリティ システムに対して提供されます。
WebLogic Server で使用するカスタム レルムは、WebLogic レルム インタフェースを実装することによって開発できます。WebLogic Server では、キャッシング システムが組み込まれたレルムをサポートして、外部ストアへの呼び出しを最小限に抑えます。カスタム レルムで実装されていない機能は、デフォルトではファイル レルムに設定されます。たとえば、一般的に、ユーザおよびグループの外部ストアはカスタム レルムで使用するよう開発しますが、ACL はデフォルトのファイル レルムで保持します。
暗号化
WebLogic Server は、ネットワーク経由で転送されるデータを保護するために、セキュア ソケット レイヤ（SSL）プロトコルをサポートしています。SSL はセキュアな Web 接続のための標準プロトコルです。WebLogic Server は、Web（HTTPS）接続、および RMI ベースのサービスを利用するスタンドアロンの Java クライアントでの SSL をサポートします。
SSL を提供するには、最初に VeriSign などの認証局（CA）から、WebLogic Server のサーバ ID を購入する必要があります。クライアントがセキュアな接続を確立する場合、WebLogic Server はクライアントへ証明書を送信し、クライアントでは接続が正しいことを確認できます。クライアントは証明書を調べて、期限が切れていないこと、送信元のサーバと一致していること、および認められた認証局による署名があることを確認します。その後、サーバとクライアントは暗号化キーを交換し、セキュアな接続を確立します。
WebLogic Server では、相互認証を要求するようにコンフィグレーションすることもできます。相互認証では、クライアントは証明書の提出を要求され、サーバはその証明書を検証してから接続を受け付けます。
WebLogic Server クラスタ
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 の通信方法
クラスタ内の 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 オブジェクトは、クラスタ内のサーバ間に分散できます。それぞれの送り先（メッセージ キューまたはトピック)は、クラスタ内の単一の WebLogic Server によって管理されます。ただし、クライアントが送り先への接続を確立するために使用する接続ファクトリは、クラスタ内の複数のサーバにデプロイできます。送り先および接続ファクトリをクラスタ全体に分散すると、管理者は、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 インスタンスがある場合、最初に起動するインスタンスは管理サーバでなければなりません。
Administration Console
WebLogic Server Administration Console は Web ブラウザで動作します。クラスタや個々の WebLogic Server など、管理するドメインのコンポーネントが、左ペインのグラフィカル ツリーに表示されます。右ペインには、左ペインで選択したオブジェクトの詳細が表示されます。 図 2-1 は、Administration Console の画面例です。
図2-1 Administration Console
Administration Console を使用してサービスをコンフィグレーションするには、左ペインでアイテムを選択し、右ペインで [コンフィグレーション] タブを選択します。Administration Console の右ペインに、コンフィグレーション可能な属性が表示されます。表示される属性の詳細については、オンライン ヘルプを参照してください。
Administration Console を使用してサービスをコンフィグレーションする通常の手順では、サービスをコンフィグレーションしてから、そのサービスをデプロイする対象（WebLogic Server）を選択します。
デプロイされた各サービスでは実行時の統計が維持されます。統計は、Administration Console の右ペインの [モニタ] タブで表示できます。
|
|
