| Oracle® Fusion Middleware Oracle Portal管理者ガイド 11g リリース1(11.1.1) B61385-02 |
|
 前 |
 次 |
この章では、Oracle Portalとそのアーキテクチャについて説明します。この章の内容は次のとおりです。
「Oracle Portalコンポーネントについて」には、Oracle Portalのソリューションとコンポーネントに関する基本的な説明があり、Oracle Portalとどのように連携して機能するのかをよりよく理解できます。
|
注意: Oracle Portalはスタンドアロンではインストールできません。Oracle Fusion Middlewareの一部としてインストールする必要があります。 |
「Oracle Portalのアーキテクチャについて」には、Oracle Portalのアーキテクチャに関する基本的な説明があります。
「Oracle Portalのキャッシュについて」では、中規模から大規模の配置における可用性とスケーラビリティを高めるために実装できるキャッシュの構成について説明します。
「WSRPおよびJPSについて」では、Web Services for Remote Portlets(WSRP)仕様とJava Portlet Specification(JPS)の概要について説明します。これらの2つの標準を使用すれば、様々なポータル製品と相互運用するポートレットの開発が可能になるため、組織内のポートレットの可用性が高まります。
Oracle Portalアーキテクチャ全体について少しでも理解しておくと、使用するOracle Portalの構成がアーキテクチャの構造にどの程度適合しているかをより深く理解できます。以降の項では、構成方針の計画に必要となる重要な概念と用語について説明します。
Oracle Portalのアーキテクチャは、次の3つの基本層で構成されています。
クライアント層
中間層
インフラストラクチャ層
クライアント層
ユーザーは、クライアント・コンピュータから中間層およびインフラストラクチャ層に接続して、情報公開のためのセルフサービス・ツールへのアクセス、アプリケーションの構築、コンテンツ管理の導入、および企業ポータル環境の管理を行います。
中間層
中間層は、通常1つのOracleホームにインストールされる一連のOracle Portalコンポーネントで、アプリケーション層とWeb層で構成されます。各企業では、1つ以上のFusion Middlewareインストールを単一のホストに配置することも、複雑なインストールの場合は複数のホストに分散することもできます。
インフラストラクチャ層
インフラストラクチャ・インストールは、ユーザーを認証し、アクセス制御情報を格納し、ユーザーがOracle Portalに対して保持している権限に基づいて必要なコンテンツをユーザーに渡すためのいくつかのコンポーネントで構成されています。中間層コンポーネントと同様に、インフラストラクチャ・コンポーネントを複数のホスト間に分散して、スケーラビリティと高可用性を実現することができます。
図1-1は、Oracle Portalアーキテクチャの3つの層を示しています。
|
注意: Oracle Portal 11g リリース1(11.1.1)は、インターネット・プロトコル・バージョン6 (IPv6)では直接サポートされていません。サポートされる構成は次のとおりです。
|
中間層は、Portalアーキテクチャの一部であり、高速で信頼性のあるパフォーマンスを実現するためにインテリジェント・データ・キャッシュを使用して、クライアントからのリクエストの受入れ、リクエストの検証、コンテンツの提供などを実行するコンポーネントが含まれています。
Oracle Portalでは、中間層は、すべてのWebリクエストを適切なプロバイダに転送することによって処理しています。中間層は、ポータル・ページが作成される場所であり、ポータル・コンテンツのキャッシュが管理される場所でもあります。中間層には、他のOracle Fusion Middlewareコンポーネントに対する機能も用意されています。
Oracle Portalの中間層の主要コンポーネントは、次の層に分割されています。
アプリケーション層
アプリケーション層は、次のコンポーネントで構成されます。
Oracle WebLogic Server: Oracle WebLogic Serverは、標準ベースのアプリケーション・サーバーです。Webサイト、J2EEアプリケーションおよびWebサービスを実行するための、包括的で全面的に統合したプラットフォームを提供します。E-Businessに向けたビジネス・プロセスの検討で直面するあらゆる問題に対応します。
Oracle WebLogic Serverは、J2EEプラットフォーム、XMLおよび新たなWebサービス標準を全面的にサポートしています。Oracle WegLogic Serverを使用して、ネットワーク・ブラウザやモバイル機器からアクセスできるカスタマイズ可能な企業ポータルを構築することで、顧客や取引先が情報に容易にアクセスできるようになります。また、ビジネス・プロセスを再定義して、社内のアプリケーションおよびデータ・ソースを顧客や取引先のものと統合できます。リアルタイムなパーソナライズによって各顧客に適した環境を提供し、ナビゲート傾向、購買、格付け、購買層などの顧客データの評価と相関分析が可能です。
また、分散システムおよび多様なユーザー・コミュニティをすべて管理および監視するために、集中型の管理、セキュリティおよびディレクトリのフレームワークを実装できます。Oracle WebLogic Serverでは、組込みのWebキャッシュ、ロード・バランスおよびクラスタリングの機能を使用して高速でスケーラブルなインターネット・アプリケーションを配置することにより、Webサイトのインフラストラクチャを最大化することができます。
Oracle WebLogic Serverは、実際にはソリューションのセットです。それぞれのソリューションには、1つ以上のコンポーネントが含まれています。コンポーネントは、サービス、APIまたはアプリケーションになります。詳細は、『Oracle Fusion Middlewareコンセプト・ガイド』を参照してください。
Portalサービス: Oracle Portalでは、Oracle HTTP Serverは、Oracle Portalに対するすべての受信リクエストを、すべてのPortalサービスが用意されたWLS_Portalインスタンスに転送することによって処理しています。Parallel Page Engine(PPE)は、Portalサービスの1つで、ポータル・ページを作成します。これ以外に、以前はmod_plsqlで提供されていたようなサービスも、Portalサービスに組み込まれました。
Fusion Middlware Control: Portal用のこの管理ツールを使用すると、クラスタの管理、サービスの開始と停止、コンポーネントの有効化と無効化、ログとポートの参照、およびサーバーのリアルタイムの監視を行うことができます。
Web層
Oracle HTTP Server: Oracle HTTP Serverは、Oracle Fusion Middlewareがサポートするすべてのプログラミング言語およびテクノロジの基盤となる配置プラットフォームです。Oracle HTTP Serverは、J2EEコンテナのフロントエンドに設定されたスケーラブルなWebリスナー、Web上で静的および動的なページとアプリケーションをホストするためのフレームワークを提供し、ロード・バランス、管理および構成を容易にする機能を備えています。
Oracle Web Cache: Oracle Portal独自のファイルベースのキャッシュと連携して、ページ定義およびコンテンツをメモリー内にキャッシュし、パフォーマンスを向上させます。Oracle Portalは、Oracle Portal全体の可用性、スケーラビリティおよびパフォーマンスを改善するために、Oracle Web Cacheと密接に統合されています。Oracle Web Cacheは、キャッシュおよび圧縮のテクノロジを組み合せて、静的および動的に生成されたポータル・コンテンツを迅速に配信します。
中間層インストールは次のコンポーネントで構成されます。
Oracle WebLogic Server、Oracle HTTP ServerおよびOracle Web Cache: 最も単純な構成で、Oracle Portalソリューション・コンポーネントは含まれていません。
Oracle Portal: Portalソリューションを、Oracle WebLogic ServerとOracle Web Cacheによって提供されるソリューションに追加します。
Oracle Reports、Oracle Business Intelligence DiscovererおよびOracle Forms: Oracle Portalなど、中間層コンポーネントのすべてが含まれています。
詳細は、次の項も参照してください。
デフォルトでは、インフラストラクチャ層はすべての認証リクエストを処理し、Oracle Fusion Middleware Metadata Repositoryをホストします。これには、Oracle PortalなどのFusion Middlewareコンポーネント、およびインフラストラクチャの他の部分で使用されるスキーマとビジネス・ロジックが含まれています。
Oracle Portalの中間層インストールには、インフラストラクチャ層が必要です。
Oracle Fusion Middleware Infrastructureには、次のものが含まれています。
Oracle Internet Directory: Oracle Portalおよび他のOracle製品のユーザー証明書とグループ・メンバーシップを格納するためのLDAPバージョン3に準拠したリポジトリ。
Oracle Application Server Single Sign-On(SSO): Oracle Portalおよび他のアプリケーションのOracle Internet Directoryを使用してユーザー証明書を認証します。ユーザーはWebポータルに1回ログインするだけで、同じユーザー名とパスワードを使用して複数のアカウントとアプリケーションにアクセスできるようになります。
Oracle Metadata Repository: このリポジトリはOracle Databaseにインストールされており、Oracle Fusion Middlewareコンポーネントの製品メタデータが含まれているスキーマのコレクションで構成されています。Oracle Portalなどの中間層コンポーネントの中には、このリポジトリに自身のメタデータを格納しているため、実行時にこのメタデータにアクセスする必要があるものがあります。
これらのコンポーネントの複数のインスタンスを複数のサーバーにインストールし、ニーズに合せてサーバーに接続することができます。Oracle Portalの配置構成については、単一のサーバーへのすべてのコンポーネントのインストールから、Oracle Portalを構成する要素が複数のサーバーに分散される複数層構成まで、様々なオプションを使用できます。
OracleAS Infrastructureインストールには、次の3つのタイプがあります。
Oracle Identity Management: Oracle Identity Managementのサービス(Oracle Internet Directory、OracleAS Single Sign-On、Oracle Delegated Administration Services、Oracle Directory Integration and Provisioning、OracleAS Certificate Authority)をインストールおよび構成します。
Oracle Metadata Repository: Oracle Metadata Repositoryが含まれている新しいOracle Databaseをインストールし、Oracle Portalを構成するデータベース・オブジェクトを格納します。
Oracle Identity ManagementのコンポーネントとOracle Metadata Repository: 前述の2つのインストール・タイプにあげたすべてのコンポーネントで構成されます。
配置チームがWebポータルを構築したら、次に、本稼働用のWebポータルを配置します。配置の成功は、遅延、エラーまたはサーバー停止がなく、エンド・ユーザーが適切な方法でコンテンツにアクセスできることを意味します。Oracle Portalは、様々なマシンに様々な構成でインストールできるため、配置の成功は、最終的にはサイトの要件に合せてポータルをどのように設定するかに依存します。この項では、構成を計画する際に役立つ背景情報について説明します。
Oracle Fusion Middlewareコンポーネントの中には、Oracle Portalのポートレット・プロバイダ脚注 1 として機能するものがあります。これは、様々なコンポーネントの情報を1つのポータル・ページに簡単に統合できることを意味しています。他のコンポーネントは、次に説明するような、Oracle Portalにとって必須のサービスを提供します。
Oracle Reports: Oracle Portalには、シンプルなレポート作成機能が含まれています。ただし、レポートが複雑になったら、レポートをOracle Reports Servicesにインポートして、用意されている機能をフル活用できます。Oracle Reports Servicesのレポートは、ポートレットとして配布できます。
|
関連項目: Oracle Fusion Middleware Oracle Reports ServicesレポートWeb公開ガイド |
Oracle Business Intelligence Discoverer: OracleBI Discovererは、ポートレット・プロバイダとして、「ワークシート」ポートレットおよび「ワークブックのリスト」ポートレットをOracle Portalユーザーに提供します。「ワークシート」ポートレットには、単一のDiscovererワークシートの情報が含まれています。ポートレットには、この情報が表、グラフまたはその両方で表示されます。「ワークブックのリスト」ポートレットには、使用できるワークブックのリストが表示されます。
|
関連項目:
|
Oracle Secure Enterprise Search: Secure Enterprise Search (SES)を使用すると、ポータルのユーザーは高機能な検索機能をポータル・ページに追加でき、様々なコンテンツ・リポジトリおよびデータソースに対する検索に使用できます。また、SESには、Oracle Portalリポジトリをクロールする機能や公開コンテンツの検索機能も用意されています。Secure Enterprise Searchの詳細は、第9章「Oracle Portalの検索機能の構成」を参照してください。
Oracle Application Server Wireless: Oracle Portalは、OracleAS Wirelessと連携して、ポータル・ページ構造を大半のワイヤレス・デバイスの小さい画面に適した形式に自動的に変換します。ワイヤレス・デバイスでは、OracleAS WirelessのXMLコンテンツを生成するポートレットのみを表示できます。
Oracle Portalの開発者は、ページ設計ツールのセットにアクセスできます。これらは、ワイヤレスの操作環境を最適化するポータル・ページを作成するときに役立ちます。開発者はこれらのツールを使用して、ワイヤレス・ユーザーに対して別個のポータル構造を構築できます。ワイヤレス・ページとポータル・ページで、ポートレット・インスタンスを共有することが可能です。これによってクライアントは、各ポートレットを再構成しなくても、ブラウザおよびワイヤレス・クライアント上のポートレットを再使用できるようになります。
詳細は、第5.7項「Oracle Portalでのモバイル・サポートの構成」を参照してください。
Oracle Enterprise Manager 11g: Oracle Enterprise Manager 11gにはFusion Middleware Controlが用意されています。Oracle Enterprise Manager 11g Fusion Middleware Controlは、監視、診断、およびOracle Portal固有の統合およびパフォーマンス設定の構成で使用できます。Oracle Portalの監視の詳細は、第8章「Oracle Portalの監視と管理」を参照してください。
Oracle Fusion Middleware Forms Services: Oracle Formsアプリケーションでは、対話的なグラフィカル・インタフェースがデータ妥当性チェックの強力なサポートと組み合されています。Forms開発者は、強力なデータ操作機能により、アプリケーションを迅速に作成できます。Fusion Middleware Forms Servicesでは、FormsアプリケーションがWeb環境のJavaクライアントに配置されます。Fusion Middleware Forms Servicesでは、クラスのダウンロード、ネットワーク通信量、およびOracle Databaseとの対話が、自動的に最適化されます。Fusion Middleware Forms ServicesアプリケーションはOracleAS Single Sign-Onで保護され、Oracle WebLogic Serverで提供されるOracle Portal環境からアクセスされます。
Oracle Application Server Single Sign-On: OracleAS Single Sign-Onは、ポータルにアクセスしようとするユーザーを認証します。詳細は、第7.1.7.1項「Oracle PortalとOracleAS Single Sign-Onの関係」を参照してください。
Oracle Internet Directory: Oracleのスケーラビリティに富んだLDAPバージョン3のサービスであり、ポータルのグループ・メンバーシップ情報をホストします。Oracle Portalは、ディレクトリに問い合せてユーザーのグループ・メンバーシップを取得し、ユーザーが何にアクセスし、変更できるのかを確認します。詳細は、第7.1.7.3項「Oracle PortalとOracle Internet Directoryの関係」を参照してください。
Oracle Delegated Administration: Oracle Portalでは、Oracle Internet Directoryに対してユーザーおよびグループ情報を問い合せるだけでなく、ユーザーおよびグループ情報を追加および変更するユーザー・インタフェースをユーザーに提供する必要があります。ディレクトリ内の情報を変更するには、Oracle Delegated Administration Servicesのユーザー・インタフェースを使用します。Oracle Portalは、ユーザーやグループを追加および変更する権限を持つユーザーに対してOracle Delegated Administration Servicesへのリンクを提供します。詳細は、第7.1.7.5項「Oracle PortalとOracle Delegated Administration Servicesの関係」を参照してください。
Oracle Directory Integration and Provisioning: Oracle Directory Integration Platformは、Oracle Portalがサブスクライブするなんらかのディレクトリ・イベント(ユーザーの削除など)が発生したときにOracle Portalに通知します。基本的にディレクトリ統合サーバーは、Oracle Portalでの変更を要する変更がディレクトリで発生したときに、Oracle Portalに通知します。詳細は、第7.1.7.4項「Oracle PortalとOracle Directory Integration Platformの関係」を参照してください。
Metadata Repository: このメタデータ・リポジトリはリポジトリ作成ユーティリティ(RCU)を使用して作成されており、Oracle Fusion Middlewareコンポーネントの製品メタデータが含まれているスキーマのコレクションで構成されています。Oracle Portalはこのリポジトリに自身のメタデータを格納しているため、実行時にこのメタデータにアクセスする必要があります。
ポータルはページのグループで構成されており、各ページは複数のリージョンに分割されています。リージョンは、特定のページの場所をページのアイテムおよびポートレットに割り当てる方法を指定します。
ユーザーがOracle Portalページをリクエストするたびに、そのページに対して選択されているポートレットおよびレイアウトに従って、ページは動的に作成および構成されます。ページを構成する要素は、通常、様々なソースから描画されます。たとえば、ページのレイアウト、外観およびユーザー・パーソナライズは、ポートレット・コンテンツから完全に分離され、すべてのページ定義の一部分としてデータベースに格納されます。この情報は、中間層にキャッシュされる場合もあります。
完全に作成されたページは、そのページのキャッシュ・プロパティに基づいてOracle Web Cacheにキャッシュされます。ただし、フルページ・キャッシュが使用されている場合、ページはOracle Web Cacheから直接提供されるため、リクエストごとに再作成されません。
ページに表示されるポートレットは、PL/SQLまたはJavaで記述できます。PL/SQLポートレットの場合、ソースはOracle Metadata Repositoryデータベースです。このデータベースには、Oracle Portalの現在のインスタンスがインストールされているデータベース、または連携型Portalアダプタを介してアクセスされるリモート・サーバーに配置されているOracle Metadata Repositoryの他のデータベースを使用できます。Javaで記述した場合、Webプロバイダは、ネットワーク(インターネットまたはイントラネット)からアクセス可能な任意の場所からポートレットを提供します。たとえば、様々なプロバイダのコンテンツを表示するポータル・ページを作成できます。プロバイダには、データベース・プロバイダ、Webプロバイダ、WSRPプロデューサなどがあります。
図1-4は、一般的なページの作成方法を示しています。今回のリリースでは、ページ・リクエスト処理のエントリ・ポイントがPPEではなく、Edge Side Includes(ESI)処理を使用したOracle Web Cacheになります。1つのページ・リクエストに含まれる様々なメタデータをより詳細なレベルでキャッシュできるようになるため、キャッシュのヒット率が高まり、ポータル・コンテンツをより細かく無効化することが可能になります。この新しい手法では、Oracle Web Cacheでのセキュアなフルページ・キャッシュもサポートされます。
図1-4に、クライアントがOracle Portalページをリクエストする場合に実行される手順を示します。
クライアント・ブラウザがポータル・ページをリクエストします。Oracle Web Cacheがこのリクエストを受け取ります。
Oracle Web Cacheがページ・スタブを取得します。ページ・スタブは、作成するページの青写真と考えてください。このページ・スタブがOracle Web Cacheにキャッシュされていない場合は、Oracle Portalインスタンスで実行されているPortalサービスによってページ・スタブが生成されます。
|
注意: Portalサービスは、ポータル・ページの作成や、ポータルおよびページのメタデータへのアクセスなどに使用されます。Parallel Page Engine(PPE)は、以前からあるPortalサービスの1つで、ポータル・ページを作成します。これ以外に、以前はmod_plsqlで提供されていたようなサービスも、Portalサービスに組み込まれました。 |
Oracle Web Cacheは、ページ・スタブを解析して、ユーザーおよびページのセキュリティ・メタデータを追加取得します。ユーザー・メタデータ(UMD)には、ユーザー名、デバイス・タイプおよび言語などがあります。このユーザー情報は、各ユーザーのセッションごとに一回収集されます。UMDがOracle Web Cacheにキャッシュされていない場合は、Oracle Portalインスタンスで実行されているPortalサービスによってページ・スタブが生成されます。ページ・セキュリティ・メタデータ(SMD)は、指定のURLのコンテンツを閲覧する権限がユーザーにあるかどうかを判断する際に使用される情報です。SMDがWeb Cacheにキャッシュされていない場合、リクエストはPortalサービスによってOracle Metadata Repositoryのポータル・スキーマに送信されます(図1-4には示されていません)。ログインしていないユーザーがプライベート・データをリクエストすると、ログインするよう求められます。そのユーザーにページを閲覧する権限がないと判断された場合は、エラー・ページが表示されます。
完全に作成されたページのコピーがキャッシュにある場合、Oracle Web Cacheはそれを返します。キャッシュにない場合は、Portalサービスのコンテンツをリクエストします。ページのコンテンツは、次のように作成されます。
Portalサービスは、キャッシュされたページ・メタデータ(PMD)のコピーをOracle Web Cacheから取得しようとします。PMD、つまりページ定義には、ページのポートレットとそのレイアウトに関する情報が含まれています。Oracle Web Cacheにキャッシュ・ミスがある場合、Portalサービスは、ポータル・キャッシュに有効なキャッシュされたコピーがあるかどうかを確認します。最終的に、キャッシュされたPMDのコピーがない場合は、Oracle Metadata Repositoryのポータル・スキーマによってPMDが生成されます。
Portalサービスは、ナビゲーション・ポートレット、バナー、タブ、サブページのリージョンなど共有のページ・コンポーネントがある場合、それらをOracle Web Cacheから取得します。これらのリクエストは同時に実行されます。有効なキャッシュされたコピーがない場合、リクエストはOracle Metadata Repositoryのポータル・スキーマに送信されます。
Portalサービスは、ページの各ポートレットについて、そのコンテンツのキャッシュされたコピーがポータル・キャッシュにあるかどうかを確認します。キャッシュ・ヒットがある場合は、キャッシュされたコンテンツが使用されます。キャッシュ・ミスがある場合は、Portalサービスが適切なプロバイダのコンテンツを取り出します。これらのリクエストは、前述の手順で説明したリクエストと同時に実行されます。各プロバイダはポートレットのコンテンツを返します。コンテンツは、Webプロバイダ、WSRPプロデューサまたはデータベース(DB)プロバイダからリクエストできます。
Oracle Web Cacheがクライアント・ブラウザに対して完全に作成されたページを返します。
Oracle Portalは、複数の通信ポイントおよびプロトコルから構成される分散アーキテクチャを実装します。ファイアウォールとプロキシの導入を含む複雑な構成の場合は、通信ポイント、およびOracle Portalの様々なコンポーネントを統合する方法を理解する必要があります。また、複数のサーバーに様々な機能を分散させるには、ノード間の通信で使用するネットワーク・プロトコルについて知っておく必要があります。
Oracle Portalのアーキテクチャは、クライアント・ブラウザ(図1-5の左端)、中間層サーバー(図の左下)、インフラストラクチャ・サーバーとリポジトリ(図の左上)の3つの基本層で構成されています。デフォルトのインストールではすべてのサーバーとリポジトリを同じホストに配置しますが、パフォーマンスと可用性を向上させるため、これらの機能は別のサーバーにインストールすることをお薦めします。
図1-5は、Oracle Portalの様々なコンポーネント間の通信フローの詳細を示しています。
次に、3つの層とそこで使用される通信プロトコルについて説明します。
クライアント
クライアントは、HTTPまたはHTTPSプロトコルを使用して、中間層の一部であるOracle Portalにリクエストを送信します。クライアントと中間層の間では、ファイアウォールおよびプロキシの使用がサポートされています。
ユーザーを認証する必要がある場合は、クライアント・ブラウザがインフラストラクチャ層のOracle HTTP Serverにリダイレクトされます。この接続はHTTPまたはHTTPSを使用し、ネットワーク環境におけるファイアウォールとリバース・プロキシの両方の実装をサポートしています。
インフラストラクチャ層
インフラストラクチャ層は、Oracle HTTP Server、OracleAS Single Sign-On、Oracle Internet DirectoryおよびOracle Metadata Repositoryから構成されています。
リクエストしたページで認証が必要な場合は、ユーザーはユーザー名とパスワードを入力するよう要求されます。この機能は、Portalサービスによって、認証のためにOracleAS Single Sign-Onへリダイレクトすることで実行されます。認証リクエストはすべてSQL*Netプロトコルを使用してやり取りされます。
OracleAS Single Sign-Onは、LDAP/Sを介して、Oracle Internet Directoryを使用してユーザー証明書を検証します。証明書はディレクトリ内で見つかったものと照合され(LDAP比較)、その結果がOracleAS Single Sign-Onに返されます。認証に成功すると、OracleAS Single Sign-Onによってシングル・サインオンCookieが作成されます。ユーザーが認証され、適切なOracle Portalセッションが作成されると、ユーザーはページおよび他のオブジェクトにアクセスできるようになります。
すべてのポータル・オブジェクトに対するアクセス制御リスト(ACL)はOracle Metadata Repositoryに保持されており、Oracle PortalはLDAP/Sリクエストを使用してOracle Internet Directoryと通信して、ディレクトリ内に定義されている適切なユーザーおよびグループ・メンバーシップ情報を問い合せます。ユーザーが最初にOracle Portalへログインすると、そのユーザーのグループ・メンバーシップがポータル・ノードへコピーされ、その層にキャッシュされます。このプロセスによって、オブジェクトの権限をすばやく検索することができます。ユーザーのオブジェクトおよびページの権限がわかると、Parallel Page Engineは適切な情報からページを生成します。
ユーザー・プロビジョニングはすべてOracle Internet Directoryに対して行われます。インフラストラクチャ層のOracle HTTP ServerとLDAPサーバー間のインタフェースは、Oracle Delegated Administration Servicesサーブレットを介しています。Oracle Delegated Administration Servicesインタフェースは、LDAP/Sプロトコルを使用してOracle Internet Directoryと通信します。
OracleAS Single Sign-Onモデルには、mod_ossoが追加されており、これによって、OracleAS Single Sign-On環境ですべてのURLが保護されます。Delegated Administration Servicesサーブレットへのコールは、mod_ossoプラグインによって保護されます。これは、Oracle Internet Directoryへのアクセスを提供する前に、ユーザーが正しく認証されていることを確認します。実際には、mod_ossoはURLを絞り込み、ユーザーが事前に認証されている場合にのみHTTPSベースのリクエストを転送します。
Oracle Directory Integration Platformでは、ローカルでキャッシュされた情報をOracle Internet Directoryでの変更に合せて自動的に最新の状態にしています。Oracle Directory Integration Platformは、ローカル・キャッシュとOracle Internet Directoryを常に同期化するだけでなく、同様にOracle Internet Directoryと外部のすべてのリポジトリを常に同期化しています。Oracle Directory Integration Platformは、LDAP/Sを介してOracle Internet Directoryと通信します。
中間層
中間層は次の層に分割されています。
中間層はアプリケーション層とWeb層から成り、Oracle Web Cache、Oracle HTTP Server、Oracle WebLogic Serverおよびその他のOracle Portal コンポーネントで構成されています。
|
注意: Oracle Web Cache、Oracle HTTP ServerおよびOracle WebLogic Serverは、スケーラビリティと可用性を向上させるために、別のホストにインストールすることができます。 |
Oracle Web Cacheを、中間層コンポーネントのフロントエンドに設定して、Oracle Portalのスループットを最適化します。ブラウザからページ・リクエストがあると、Oracle Web CacheはそのURLを評価し、可能な場合はキャッシュからリクエストされたページを提供します。リクエストされたページが以前にキャッシュされていない場合、生成のためにそのリクエストはオリジナル・サーバー(この場合はOracle HTTP Server)に転送されます。Oracle Web Cacheは、Webアクセラレータとして、次のコンポーネントとの間でHTTPまたはHTTPS通信を使用できるようにします。
クライアント・ブラウザ
適切なオリジナル・サーバー
オリジナル・サーバーとクライアント・ブラウザの両方
Parallel Page Engine(PPE)は、Oracle Containers for J2EE内でサーブレットとして動作します。サーブレットに対するURLリクエストは、Oracle HTTP Serverのプラグインであるmod_weblogicを介して転送されます。mod_weblogicは、業界標準に準拠したプラグインで、AJP(Apache Java Protocol)を使用してOracle Containers for J2EEと通信します。
WSRPコンテナは、WSRP仕様およびJava Specifications Request(JSR)168 APIを実装するJavaポートレット・コンテナです。
PPE自体は、HTTPSベースの通信を介して、データベース・プロバイダ、WebプロバイダおよびWeb Services for Remote Portlets(WSRP)プロデューサに対してリクエストを行います。データベース・プロバイダに対するレンダリング・リクエストは、PortalサービスへのURLループバックを介して行われますが、Webプロバイダのコールは、HTTPまたはHTTPSを介してSOAPベースのメッセージ・プロトコルを使用して行われます。また、WSRPプロデューサのコールは、Web Services Definition Language(WSDL)URLを使用するWSRPの通信プロトコルを使用して行われます。
Webプロバイダは、Oracle Metadata Repositoryの情報が必要になると、HTTPまたはHTTPSを介してSOAPベースのメッセージ・プロトコルを使用して、PDKによって適切なコールを行います。
Oracle Web Cacheコンポーネントは、無効化ベースのキャッシュ法を使用します。リクエストされたURLをキャッシュから提供できる場合は、指定されたURLが無効でないかぎり、そのURLは正しいとみなされます。ユーザーがOracle Portalの操作環境をカスタマイズしている場合、またはユーザーの変更を使用するように構成されている権限の場合、Oracle PortalはOracle Web Cache内で該当するキャッシュ・オブジェクトを無効化します。これを行うために、Oracle Portalは、Oracle Web Cacheの無効化用ポートに対して、Oracle Metadata Repositoryから直接HTTPSベースのリクエストを発行します。
Oracle Portalは、次の場所でデータをキャッシュします。
ブラウザ: リクエスト間で変更されないデータをキャッシュできます(有効期限ベースのページなど)。
Oracle Web Cache: 様々なタイプのポータル・データがメモリー内キャッシュ・システムに保存されます。第1.3.1項「Oracle Web Cacheについて」を参照してください。
ポータル・キャッシュ: 様々なタイプのポータル・データは永続的なファイル・システムベースのキャッシュにも保存されます。第1.3.2項「ポータル・キャッシュについて」を参照してください。
Oracle Portalは、次の3つの方法を使用してWebページとコンテンツをキャッシュします。
無効化ベースのキャッシュは、Oracle Web Cacheによって使用されます。アイテムは明示的に無効化されるまでキャッシュに残ります。たとえば、ユーザーがアイテムを更新した場合、キャッシュを無効化する必要があります。アップデート処理の一環として、Oracle Metadata Repositoryまたはプロバイダは無効化メッセージをOracle Web Cacheに送信します。無効化されたアイテムに対するリクエストが次に発生したときに、そのアイテムはキャッシュ内で更新されます。無効化ベースのキャッシュに対して有効期間を設定できます。詳細は、第6.7.4.3項「無効化ベースのキャッシュの有効期間の設定」を参照してください。
妥当性チェック・ベースのキャッシュは、ポータル・キャッシュによって使用されます。ポータル・キャッシュ内のアイテムが使用される前に、Portalサービスは、Oracle Metadata Repositoryまたはプロバイダにアクセスして、キャッシュされたアイテムがまだ有効かどうかを確認します。
有効期限ベースのキャッシュは、ポータル・キャッシュ、Oracle Web Cacheおよびブラウザによって使用されます。有効期限ベースのポートレットはポータル・キャッシュにキャッシュされるのに対し、有効期限ベースで作成されたページはOracle Web Cacheにキャッシュされます。アイテムの保持期間には、アイテムがキャッシュ内で有効である期間を指定します。この期間が経過したら、更新が必要になります。有効期限ベースのキャッシュを使用するページは、ユーザーのブラウザでもキャッシュされる場合があります。
キャッシュは次のレベルで実行されます。
ユーザー: 各ユーザーに対してデータのコピーが個々にキャッシュされます。
システム: すべてのユーザーに対して単一のデータのコピーがキャッシュされます。
Oracle Web Cacheは強力なサーバー・アクセラレータおよびロード・バランスのソリューションです。Oracle Portalを実行するには、Oracle Web Cacheが必要です。Oracle Web Cacheにはインテリジェント・キャッシュ、ページ・アセンブリおよび圧縮の機能が用意されています。Oracle Web Cacheは、静的および動的なWebコンテンツを迅速に配信し、Oracle Fusion Middlewareにロード・バランスおよびフェイルオーバーの機能を提供します。
中規模から大規模の配置の可用性とスケーラビリティを高めるには、Oracle Web Cacheの複数のインスタンスをキャッシュ・クラスタのメンバーとして実行するように構成します。クラスタは、協調するOracle Web Cacheインスタンスの集合で、連携して1つの論理キャッシュを提供します。キャッシュ・クラスタは、障害検出とフェイルオーバーを提供することにより、Webサイトの可用性を高めます。Oracle Web Cacheインスタンスで障害が発生すると、キャッシュ・クラスタの他のメンバーが障害を検出して、障害が発生したクラスタ・メンバーのキャッシュ・コンテンツの所有権を引き継ぎます。これは、リクエストを所有者のキャッシュ・ノードへ転送した後、リクエストを受け取るノードがコンテンツを保持しているために実現されます。
Webサイトのコンテンツを複数のOracle Web Cacheサーバーに分散することで、より多くのコンテンツをキャッシュでき、より多くのクライアント接続をサポートできるため、Webサイトの容量を拡張できます。複数のリクエストが並行して実行されることにより、同時に処理されるリクエストの数が増えるため、CPUの処理能力を高めることができます。
Oracle Portalは、Web Cacheのオリジナル・サーバーとして機能し、次のWeb Cache機能を利用します。
動的に生成されたユーザー固有のページ構造およびポートレットのコンテンツのキャッシュ
ファイングレイン・キャッシュ制御
無効化ベースのキャッシュ
レイヤー7のロード・バランスおよびフェイルオーバー検出
パフォーマンス保証とサージ保護
ポータル・サイトの配置には、次の選択肢があります。
同じ場所: Web Cacheは、Oracle Portal中間層と同じ物理サーバーで動作します。この構成は、中間層のスケーラビリティが重要ではない、小規模でデータ量の少ないサイトに適しています。
専用: Web Cacheを、1つ以上のOracle Portal中間層サーバーの前に位置する専用サーバーに配置します。通常は、専用の配置では他のサーバー・プロセスとのリソース競合のリスクがないため、同じ場所での配置よりも優れています。Oracle Web Cacheは一般的なハードウェアで十分に機能するため、専用の配置は、ハードウェアの費用の点では負担になりません。
データ量の多い、中規模から大規模のビジネスWebサイトでは、次の理由により、専用配置トポロジの方が優れています。
リソース競合がない: Oracle Web CacheとOracle Portal中間層を別のサーバーにインストールすることで、複数のサービス間でのハードウェア・リソースの競合が発生しません。
パフォーマンスの保証およびサージ保護: 中間層サーバーとキャッシュ・サーバーを分離するトポロジによって、複合的な障害の発生を最小限に抑えることができます。Oracle Web Cacheでは、Webサーバーの負荷が許容量レベルを超えた場合でもサイトのパフォーマンスとスケーラビリティを保証する特許出願中の技術を使用しています。サージ保護メカニズムでは、システムの負荷が過剰な状態を検出することで、トラフィック・スパイクやDoS攻撃に対処するための重要なバッファを提供します。
サーバー・アフィニティ: Oracle Web Cacheを使用して、クラスタの中で複数のOracle Portal中間層サーバーとプロバイダどうしの負荷を均衡化できます。状態の保持が必要な場合は、Cookieを使用して、特定のサーバーに対する永続的な(スティッキーな)接続を維持できます。
データ量が非常に多いサイトでシングル・ポイント障害を回避するために、ロード・バランス・ルーター(LBR)の背後に、Oracle Web Cacheを実行する複数のノードを配置することができます。Oracle Portalを複数配置している場合は、各ポータル・サイトで専用のWeb Cacheサーバーを使用することができます。1つ以上のサイトで、1つのWeb Cacheサーバーを共有することもできます。同様に、プロバイダとポータル・サイトでWeb Cacheを共有することも、プロバイダをホストしているWebサーバーの前に専用のWeb Cacheを配置することも可能です。Oracle Web Cacheの構成の詳細は、第6.7項「Oracle Web CacheにキャッシュされたOracle Portalコンテンツの管理」を参照してください。
Oracle Web Cacheのクラスタは、フェイルオーバーを提供するだけでなく、中間層に転送する負荷を均衡させます。
所有者ノードへ最初のリクエストがあった後、コンテンツはリクエスト側のすべてのインスタンスへキャッシュされます。図1-6では、LBRは着信リクエストを3つのOracle Web Cacheインスタンスに配布しています。リクエストを受け取ったノードでオンデマンド・コンテンツを利用できない場合は、他のインスタンスでキャッシュされたコンテンツが調べられ、リクエストと一致するページがブラウザへ返されます。
Oracle Web Cacheのクラスタ機能を利用するには、各インスタンスをキャッシュ・クラスタのメンバーとして構成する必要があります。この設定では、Oracle Web Cacheインスタンスおよびそれと対応する中間層インスタンスとの間に1対1関係はありません。図1-6に示すように、Oracle Web Cache 1は中間層1、2および3の間でロード・バランスを行います。Oracle Web Cache 2および3も同様に行います。
|
関連項目: 『Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache』 |
キャッシュとパフォーマンスの詳細は、Oracle Technology Network(OTN)を参照してください。
ポータル・キャッシュは、Oracle Portalのページおよびポートレット用のファイル・システムベースのキャッシュです。ポータル・キャッシュでは、妥当性チェック・ベースのキャッシュおよび有効期限ベースのキャッシュがサポートされています。
ポータル・キャッシュは、次の2つの種類のキャッシュで構成されています。
コンテンツ・キャッシュには、Oracle Portalで生成された、ユーザー・レベルおよびシステム・レベルのコンテンツが含まれています。この中には、ページ・メタデータ、データベース・ポートレット、Webポートレット、ドキュメント、スタイル・シート、イメージおよびフルページ・キャッシュが含まれています。
Oracle Portalは、セッションCookieを使用して、各ポータル・ユーザーのセッションの詳細を保持します。このセッションCookieは暗号化されており、この中にはデータベース・ユーザー名、軽量ユーザー名、セッションのグローバリゼーション・サポート特性などの重要な情報が含まれています。Portalサービスがポータルのリクエストを実行するには、セッションCookieからデータベース・ユーザー名を取得する必要があります。各ユーザーのリクエストでコストの高い復号化処理を避けるために、PortalサービスはセッションCookieをいったん復号化し、関連するCookie詳細をメモリー内のセッション・キャッシュに置きます。メモリー内のセッション・キャッシュが、JVMによってガベージ・コレクションに使用される場合があるので、セッションの詳細もファイル・システムにキャッシュされます。
ポータル・コンテンツとセッション・キャッシュ・コンテンツは、ファイル・システム上にあります。通常は、ファイルDOMAIN_HOME\config\fmwconfig\servers\WLS_PORTAL\applications\portal\configuration\portal_cache.conf内で構成されます。Fusion Middleware ControlからOracle Portalのコンテンツ・キャッシュを指定できます。詳細は、第5.6.6項「Fusion Middleware Controlを使用したポータル・キャッシュの構成」を参照してください。
複数の中間層の構成では、共有ファイル・システム上の各中間層に対してポータル・キャッシュを設定できます。これにより、各中間層はそれぞれのキャッシュからコンテンツを取得しないで、キャッシュされたコンテンツを共有できるようになります。
たとえば、ある中間層は、アイテムに対するリクエストをポータル・キャッシュにキャッシュしてから処理します。複数の中間層を持つ構成に対してロード・バランス・ルーターを使用するため、アイテムに対する次のリクエストは別の中間層で処理される場合があります。各中間層のポータル・キャッシュが共通のファイル・システム上で共有されている場合、この中間層はキャッシュされたコンテンツにアクセスできます。
ポータル・キャッシュを構成するための様々なパラメータがあります。
キャッシュの場所
総キャッシュ・サイズ
キャッシュ可能な最大ファイル・サイズ
キャッシュされたファイルをキャッシュ・システムに保持できる最大時間
キャッシュ記憶域の消去
|
関連項目:
|
Oracle Portalは、Oracle Web Cacheとポータル・キャッシュの2つのキャッシュ・システムを使用します。Oracle Web Cacheでは、無効化ベースのキャッシュと有効期限ベースのキャッシュがサポートされています。ポータル・キャッシュでは、妥当性チェック・ベースのキャッシュと有効期限ベースのキャッシュがサポートされています。
キャッシュの無効化は、次の2つのグループに分類できます。
強い無効化
強い無効化は、1つのブラウザ・リクエストが行われている間キューに入っており、Oracle Portalのユーザー・インタフェース処理が完了すると処理されます。この結果はすぐに表示されます。大半のページ編集およびすべてのポートレットのカスタマイズは、強い無効化として処理されます。
弱い無効化
弱い無効化は、多数のブラウザ・リクエストが行われている間キューに保持され、弱い無効化のデータベース・ジョブによって後で処理されます。ユーザーまたはグループにページに対する権限を付与するなど、セキュリティに関する変更は弱い無効化として処理されます。
キャッシュ無効化のリソース要件
無効化は、編集とパーソナライズに基づいてキューに蓄積されます。実行する処理が多いほど、送信される無効化の件数が多くなります。個々の処理では、ポータル・オブジェクトやユーザーが多いほど、対応する無効化の処理に必要なリソースも増えます。たとえば、ユーザー・グループのアクセス権限を変更するには、グループの各ユーザーに対してデータを無効化する必要があります。したがって、グループが大きいほど無効化に必要なリソースが多くなります。別の例を考えてみましょう。大量のページを一括操作で削除する場合、無効化に必要なリソースは削除するページの数に比例します。無効化の処理では、記憶域、CPU、通信の各リソースが必要になります。したがって、キャッシュの無効化が大量に実行されると、システムの処理速度が低下する場合があります。その理由は次のいずれかになります。
Oracle Web Cacheとの通信
強い無効化または弱い無効化のどちらかが処理されるときに、無効化メッセージを送信するために、Oracle Metadata RepositoryからのOracle Web Cacheの無効化用ポートでTCP/IP接続が確立されます。
強い無効化および弱い無効化のどちらの場合でも、キューに入れられたすべてのメッセージが、TCP/IP接続を使用してOracle Web Cacheへ送信されます。Oracle Web Cacheはこれらの無効化メッセージを受信し、キャッシュされたデータを無効化しようとします。この負荷は、データ・リクエストに応答するOracle Web Cacheの能力に影響を与えることがあります。
キャッシュ無効化キューの記憶域
強い無効化と弱い無効化の両メッセージは、Oracle Metadata Repositoryのデータベース表内でキューに入れられます。キューのサイズが大きくなるにつれ、キューを保持するためのデータベース・リソースが、より多く必要になります。
キャッシュ無効化キューの最適化
強い無効化または弱い無効化メッセージの処理中に、キューの最適化によって、重複した、または不要な無効化メッセージが削除されます。たとえば、ページ・グループが無効化される場合、ページ・グループ内の個々のページに対する無効化メッセージは不要です。大量の無効化メッセージがキューに入れられている場合は、最適化のプロセスに長時間かかることがあります。
WSRP仕様とは、Webサービス標準の1つで、ポータルや他の中間Webアプリケーションでのビジュアルなユーザー向けWebサービスのプラグ・アンド・プレイを可能にします。WSRPは標準であるため、特定の言語(Java、.NET、Perlなど)をベースにした標準対応コンテナと、あらゆるWSRPポータルとの間の相互運用性が実現します。そのため、WSRP対応のコンテナにデプロイしたポートレットは、言語に関係なく、この標準をサポートするすべてのポータルにレンダリングできます。WSRPの詳細は、http://docs.oasis-open.org/wsrp/v2/wsrp-2.0-spec.pdfを参照してください。
JPSはJSR 168とJSR 286を基盤としています。Javaを使用する標準ベースのポートレットを構築するAPIのセットを定義します。この仕様に従って構築されたポートレットは、ローカルでポータルにレンダリングできるほか、リモートでポートレットをレンダリングするWSRPコンテナにデプロイすることもできます。JSR 168の詳細は、http://jcp.org/aboutJava/communityprocess/final/jsr168/index.htmlを参照してください。
|
関連項目: 『Oracle Fusion Middleware Developer's Guide for Oracle Portal』 |
これで、Oracle Fusion Middlewareのアーキテクチャ、Oracle Portalがどのように適合しているか、Oracle Portalのキャッシュの機能について、およびWSRPプロデューサについての基本的な説明を終わります。次は、第2章「Oracle Portalの計画」に進んでください。この章を読み終えると、インストールをどのように構成したらよいかがわかるようになります。
脚注の凡例
脚注1: ポートレットとして表現されるアプリケーションと情報ソースは、プロバイダを介してポータルと通信します。ポートレットはプロバイダを1つしか持つことができませんが、プロバイダは基盤となるアプリケーションまたは情報ソースを公開する1つ以上のポートレットを持つことができます。
