第 5 章ポータルの設計

この章では、ポータルの高レベルおよび低レベルの設計を行う方法について説明し、設計計画の各部分の設計に必要な情報を提供します。

ポータルの設計への取り組み方

Sun Java^TM System Portal Server の配備のこの時点で、業務および技術上の要件を確認し、それらの要件を関係者に伝えて承認を得ているはずです。これで、設計段階を開始できます。設計段階では、高レベルと低レベルの設計を行います。

高レベルのポータルの設計は、システムのアーキテクチャを明確にし、ソリューションの低レベルの設計の基になります。さらに、高レベルの設計では、事前に確定した業務および技術上の要件を満たす論理アーキテクチャを記述する必要があります。論理アーキテクチャは、システム全体を構成するさまざまなアプリケーションに従って、またユーザーがシステムと対話する方法に従って分解されます。一般に、論理アーキテクチャには、Portal Server Secure Remote Access (SRA)、高可用性、セキュリティ (Access Manager を含む)、および Directory Server アーキテクチャコンポーネントが含まれます。詳細は、「論理ポータルアーキテクチャ」を参照してください。

高レベルおよび低レベルの設計では、ポータルの制御を超える要素、つまりネットワーク、ハードウェアの障害、不適切なチャネルの設計なども考慮する必要があります。

完成した高レベルの設計を基に低レベルの設計を行うことができます。低レベルの設計では、物理アーキテクチャ、ネットワークインフラストラクチャ、ポータルデスクトップのチャネルおよびコンテナの設計、実際のハードウェアおよびソフトウェアのコンポーネントなどのアイテムを指定します。高レベルおよび低レベルの設計を完了すると、組織内で試験的な配備のテストを開始できます。

ポータルの高レベルの設計の概要

高レベルの設計は、業務の要件と技術要件の両方をサポートするアーキテクチャに取り組む最初の段階です。高レベルの設計では、次のような問いに答えます。

ポータルの低レベルの設計の概要

低レベルの設計では、ポータルソリューションを構築するために使用するプロセスおよび標準の指定、また次のものを含む実際のハードウェアおよびソフトウェアコンポーネントの指定に焦点を合わせます。

Portal Server サーバーの複雑性。

ネットワーク接続: ポータルコンプレックスを「外の世界」にどのように接続するかを示します。ここでは、セキュリティの問題、プロトコル、速度、および他のアプリケーションまたはリモートサイトへの接続を考慮する必要があります。

情報アーキテクチャ: ユーザーインタフェース、コンテンツのプレゼンテーションおよび構成、データソース、フィードなど。

Access Manager のアーキテクチャ: 長期にわたる成功に重要な、組織、サブ組織、ロール、グループ、ユーザーなどの方針および設計など。

統合方針: さまざまな情報を統合し、新しい方法でユーザーをまとめるための統合点としてポータルがどのようにふるまうかなど。

論理ポータルアーキテクチャ

論理ポータルアーキテクチャは、次のものを含む (しかし次のものに限定されない)、ポータルを構成するすべてのコンポーネントを定義します。

Portal Server そのもの

RDBM からのコンテンツ

サードパーティのコンテンツプロバイダ

カスタム開発のプロバイダおよびコンテンツ

メッセージングシステムやカレンダシステムなどのバックエンドシステムとの統合

配備のための Web コンテナ

コンテンツ管理システムのロール

顧客リソースの管理

ポータルがオープンモードまたはセキュアモード (Secure Remote Access が必要) のどちらで動作するか

使用の見積もり: これには、登録ユーザーの総数、1 日にログインする登録ユーザーの割合の平均、1 日に同時にログインするユーザーの平均の数、平均ログイン時間、ログインしたユーザーが選択したコンテンツチャネルの平均数、ログインしたユーザーが選択したアプリケーションチャネルの平均の数に対する予測が含まれます。

また、次の 3 つのネットワークゾーンがどのように設計に適合するかを考慮する必要があります。

インターネット: 一般のインターネットとは、イントラネットと DMZ の外側にあるネットワークのことです。ユーザーのポータルサーバーとゲートウェイにここから安全にアクセスします。

非武装ゾーン (DeMilitarized Zone、DMZ): 2 つのファイアウォールの間にある安全な領域であり、無許可の侵入を防止し、内部リソースへのアクセスを可能にします。ゲートウェイは、この場所に存在し、ここからアプリケーションサーバーやコンテンツサーバーからのトラフィックをインターネットへ安全に転送できます。

イントラネット: すべてのリソースサーバが含まれます。これには、イントラネットアプリケーション、Web コンテンツサーバー、およびアプリケーションサーバーが含まれます。Portal Server および Directory Server はここに存在します。

論理アーキテクチャは、次のようなものを含む、ポータルデスクトップの見た目と使い心地を記述します。

サイトが必要とする場合、キャッシングの方針も論理アーキテクチャに含めます。ユーザーに返されるページに多数のイメージへの参照が含まれる場合、Portal Server がそれらのイメージをすべてのユーザーに配信できます。ただし、それらのタイプの要求を逆プロキシタイプのキャッシング装置にオフロードできる場合、Portal Server が他のユーザーにサービスを提供できるようにシステムリソースを解放できます。また、キャッシング装置をエンドユーザーの近くに配置することによって、それらのイメージをエンドユーザーにいくらか速く配信することができるので、エンドユーザーの使い勝手がよくなります。

Portal Server とスケーラビリティ

スケーラビリティとは、パフォーマンスを低下させることなく、処理リソースを追加することによって、増加するユーザー人口に対応するシステムの能力のことです。システムをスケーリングするための 2 つの一般的な方法には、垂直方向のスケーリングと水平方向のスケーリングがあります。このセクションの主題は、Portal Server 製品へのスケーリング技術の応用です。

垂直方向のスケーリング

垂直方向のスケーリングでは、CPU、メモリー、Portal Server の複数のインスタンスなどのリソースが 1 つのマシンに追加されます。これより、より多くのプロセスインスタンスが同時に実行できます。Portal Server では、必要な CPU の数に計画およびサイズ指定することによってこれを利用できます。詳細は、第 4 章「配備前の注意点」を参照してください。

水平方向のスケーリング

水平方向のスケーリングでは、マシンが追加されます。これは、複数の同時処理とワークロードの分散も可能にします。Portal Server では、Portal Server、Directory Server、および Access Mangaer を異なるノードで実行できるので、水平方向のスケーリングを利用します。水平方向のスケーリングは、さらに CPU を追加するなどして、垂直方向のスケーリングも利用できます。

また、サーバーコンポーネントインスタンスを複数のマシンにインストールすることによって、Portal Server インストールを水平方向にスケールできます。インストールされた各サーバーコンポーネントインスタンスは、HTTP プロセスを実行し、この HTTP プロセスはインストール時に決定された番号の TCP/IP ポートで待機します。ゲートウェイのコンポーネントは、ラウンドロビンアルゴリズムを使用して新しいセッション要求をサーバーインスタンスに割り当てます。セッションが確立されている間は、クライアントに格納された HTTP cookie がセッションサーバーを示します。それ以降の要求はすべてそのサーバーに送られます。

「Portal Server 構築モジュールの使用」のセクションでは、最適のパフォーマンスと水平方向のスケーラビリティを提供する特定のタイプの構成への取り組み方について説明します。

Portal Server と高可用性

高可用性は、ポータルプラットフォームに週 7 日 24 時間アクセス可能であることを保証します。今日の組織では、データやアプリケーションが常に利用可能であることが要求されます。高可用性は、ミッションクリティカルなアプリケーションのみでなく、IT インフラストラクチャ全体にも要求されます。

システムの可用性は、コンピュータのハードウェアとソフトウェアのみでなく、システムの停止時間の 80 パーセントの原因である人およびプロセスによっても影響を受けます。可用性は、システムの管理を計画的に行うことで、また人為ミスの影響を最小限にする業界の最良の方法によって向上できます。

考慮する必要がある重要な問題の 1 つに、すべてのシステムの可用性要件が同じレベルであるとはかぎらないという点があります。ほとんどのアプリケーションは、次の 3 つのグループに分類できます。

アプリケーションがミッションクリティカルになるほど、シングルポイント障害 (Single Point of Failure、SPOF) をなくし、人およびプロセスの問題を解決するために可用性にさらに焦点を合わせる必要がでてきます。

システムが常に利用可能であっても、障害回復のインスタンスがエンドユーザーに透過でない場合があります。障害の種類によっては、ユーザーはポータルアプリケーションのコンテキストを失うことがあり、ポータルデスクトップにアクセスするためにもう一度ログインする必要がある場合があります。

システムの可用性

システムの可用性は、システムの稼働時間の割合で表現されます。システムの可用性を計算するための基本的な式を次に示します。

たとえば、サービスレベル契約の稼働時間が 4 桁 (99.99 %) である場合は、1 ヶ月にシステムが約 7 時間利用できなくなることを意味します。さらに、システムの停止時間は、システムが利用できない時間の合計です。この合計には、ハードウェアの障害やネットワークの停止などの計画外の停止時間のみでなく、計画された停止時間、予防保守、ソフトウェアのアップグレード、パッチなどの時間も含まれます。

システムを週 7 日間、1 日 24 時間利用できるようにする場合は、高可用性を保証するため、計画された停止時間と計画されていない停止時間を避けるためにアーキテクチャには冗長性を含める必要があります。

高可用性のレベル

高可用性は、オンまたはオフにできるスイッチであるだけではありません。高可用性のさまざまなレベルは、システムが障害から回復する能力とシステムの可用性を測定する方法も指します。高可用性のレベルは、特定組織の障害の許容性の要件とシステムの可用性の測定方法によって決定されます。

たとえば、別のログイン画面にリダイレクトされた要求が成功したとみなされるように、組織がシステムの障害発生後の再認証の必要を許容する場合があります。他の組織では、システムが引き続きサービスを提供している場合でも、これは失敗とみなされる可能性があります。

特定のポータルアプリケーションのコンテキストはフェイルオーバー後に失われることがあるので、セッションのフェイルオーバーのみが透過なフェイルオーバーの究極の解決策ではありません。たとえば、ユーザーが NetMail Lite でメッセージを作成し、その電子メールにいくつかの文書を添付してから、サーバーに障害が発生した場合を考えてみてください。ユーザーは別のサーバーにリダイレクトされ、NetMail Lite はユーザーのセッションとメッセージの下書きを失います。コンテキストデータを現在の JVM^TM に格納するその他のプロバイダでも同じ問題が発生します。

Portal Server の高可用性の実現

Portal Server の可用性を高めるには、次の各コンポーネントの可用性を高める必要があります。

ゲートウェイ: ゲートウェイで使用するロードバランサは、障害が発生したゲートウェイコンポーネントを検出し、新しい要求を他のゲートウェイにルーティングします。ロードバランサは、ワークロードをサーバープールにインテリジェントに分散する能力もあります。障害が発生したゲートウェイが回復すると、ルーティングが元に戻ります。ゲートウェイコンポーネントはステートレスなので (セッション情報はクライアントで HTTP cookie に格納される)、障害が発生したゲートウェイを迂回した再ルーティングはユーザーには透過です。

Portal Server: オープンモードでは、ロードバランサを使用して障害が発生したコンポーネントを検出し、要求を他のサーバーにリダイレクトします。セキュアモードでは、ゲートウェイコンポーネントが障害の発生したサーバーコンポーネントの存在を検出し、要求を他のサーバーにリダイレクトします。Web コンテナが Web Server であるかぎりこのようになります。

Directory Server: 多数のオプションが、LDAP ディレクトリの可用性を高めます。詳細は、「構築モジュールと高可用性のシナリオ」を参照してください。

Netlet プロキシとリライタプロキシ: ソフトウェアのクラッシュが発生した場合、watchdog プロセスがプロキシを自動的に再起動します。さらに、ゲートウェイがプロキシのロードバランスと障害検出フェイルオーバーを実行します。

Portal Server システムの通信リンク

図 5-1 は、ソリューションの可用性に重要な Portal Server システムのプロセスおよび通信リンクを示しています。

この図では、Web Server 技術で稼働する Portal Server インスタンスがボックスで囲まれています。このインスタンスには、5 つのサーブレット (認証、Access Manager 管理コンソール、ポータルデスクトップ、通信チャネル、および検索) と 3 つの SDK (Access Manager SSO、Access Manager ロギング、および Access Manager 管理) が含まれています。認証サービスサーブレットは、LDAP サービスプロバイダモジュールも利用します。

ユーザーは、ブラウザまたはゲートウェイのどちらかを使用して Portal Server と通信します。このトラフィックは、適切なサーブレットにダイレクトされます。通信は、認証サービスの LDAP モジュールと LDAP 認証サーバー間、通信チャネルサーブレットと SMTP/IMAP メッセージングサーバー間、Access Manager SSO SDK と LDAP サーバー間、Access Manager 管理 SDK と LDAP サーバー間で行われます。

Portal Server は、認証シングルサイオン (セッション) 管理、ポリシー、およびプロファイルデータベースアクセスのために Access Manager 上に構築されます。したがって、Portal Server は可用性と障害許容性に関して Access Manager のすべての利点 (および制約) を継承します。

設計により、Access Manager のサービスは、ステートレス、またはサービスがコンテキストデータを共有できるのどちらかになります。サービスは、サービスに障害が発生した場合に前の状態に戻ることができます。

Portal Server では、ポータルデスクトップサービスと NetMail サービスはインスタンス間で状態データを共有しません。これは、インスタンスのリダイレクトによって、有効になったサービスに対してユーザーコンテキストが再作成されることを意味します。通常、リダイレクトされたユーザーはこれに気がつきません。これは、Portal Server サービスがユーザーコンテキストをユーザーのプロファイルから、また要求に格納されたコンテキストデータを使用することによって再作成できるためです。これは一般にインストール後即使用可能なサービスに当てはまりますが、チャネルやカスタムコードには当てはまらないことがあります。開発者は、インスタンスのフェイルオーバー時にコンテキストを失うのを避けるためにステートフルチャネルを設計しないように注意する必要があります。

プロファイルデータベースサーバー: プロファイルデータベースサーバーは、Directory Server ソフトウェアによって実装されます。このサーバーは厳密には Portal Server の一部ではありませんが、このサーバーの可用性とデータベースの完全性はシステムの可用性に欠かせません。

認証サーバー: これは LDAP 認証のためのディレクトリサーバーです (通常、プロファイルデータベースサーバーと同じサーバー)。このサーバーには、プロファイルデータベースサーバーと同じ高可用性技術を適用できます。

SRA ゲートウェイとプロキシ: SRA ゲートウェイは、状態情報をエンドユーザーに透過に再作成できるため、ステートレスとみなすことのできるスタンドアロンの Java テクノロジプロセスです。ゲートウェイプロファイルは、Portal Server インスタンスのリストを維持し、ゲートウェイインスタンス間でラウンドロビン方式のロードバランスを行います。ゲートウェイの前ではセッション固定の必要はありませんが、セッションが固定されると、パフォーマンスが向上します。一方、Portal Server インスタンスに対するセッション固定は SRA によって実施されます。

Portal Server 構築モジュールの使用

Portal Server の配備は多くの他のシステムも関係する複雑な処理であるため、ここでは最高のパフォーマンスと水平方向のスケーラビリティを提供する特定の構成について説明します。この構成は、Portal Server 構築モジュールと呼ばれます。

Portal Server 構築モジュールは、共有サービスに限定的に依存、またはまったく依存しないハードウェアおよびソフトウェアの構成です。一般的な配備では、複数の構築モジュールを使用して、最高のパフォーマンスと水平方向のスケーラビリティを実現します。図 5-2 は、構築モジュールのアーキテクチャを示しています。

構築モジュールと高可用性のシナリオ

Portal Server は、高可用性に関して次の 3 つのシナリオを提供します。

ここでは、高可用性の観点から、これらのアーキテクチャの実装方法について、また構築モジュール概念を活用する方法について説明します。


注	Portal Server 構築モジュールは、単なる推奨構成です。場合によっては、別の構成のほうがスループットが若干よくなることがあります。この場合、一般的に構成はより複雑になります。たとえば、4 CPU システムに Portal Server の別のインスタンスを追加すると、スループットが最高 10 % 向上する可能性がありますが、単一システムのみを使用する場合でもロードバランサを追加する必要があるという代償を払う必要があります。

表 5-1 は、これらの高可用性シナリオと、シナリオをサポートする技術の要約です。

表 5-1 Portal Server 高可用性シナリオ
コンポーネントの要件	ベストエフォート配備に必要ですか ?	NSPOF 配備に必要ですか ?	透過フェイルオーバー配備に必要ですか ?
冗長ハードウェア	はい	はい	はい
Portal Server の構築モジュール	いいえ	はい	はい
マルチマスター構成	いいえ	はい	はい
ロードバランス	はい	はい	はい
ステートレスなアプリケーションとチェックポイントメカニズム	いいえ	いいえ	はい
セッションのフェイルオーバー	いいえ	いいえ	はい
Directory Server クラスタ	いいえ	いいえ	はい

ベストエフォート


注	ロードバランスは、Web Server 製品では出荷時の状態では提供されていません。

このシナリオでは、可用性が続くように、Sun Fire UltraSPARC#174: III マシンなどの、ハードウェアが保護された単一ノードに Portal Server と Directory Server をインストールします。Solaris^TM オペレーティング環境システムを保護するには、デフォルトの設定を変更する必要があります。

このタイプのサーバーではハードウェアが完全に冗長であり、次のものを備えています。冗長電源、冗長ファン、冗長システムコントローラ、動的再構成、CPU ホットプラグ、オンラインアップグレード、および RAID 0+1 (ストラインピングにミラーリングもプラス) またはボリューム管理システムを使用する RAID 5 で構成できるディスクラック (ディスククラッシュ発生時にデータが失われるのを防止する)。図 5-3 は、構築モジュールのアーキテクチャを使用する、小規模のベストエフォート配備を示しています。

このシナリオでは、1 つの構築モジュールには、メモリーの割り当ては 4 CPU × 8G バイト RAM (4 × 8) で十分です。Access Manager コンソールは、他のリソースと共有できるように構築モジュールの外にあります。実際のサイズの計算結果は、これとは異なる割り当て量になる場合があります。

このシナリオは、タスククリティカルな要件には十分です。このシナリオの主な弱点は、システムのシャットダウンが必要な保守作業によってサービスが中断されるということです。

SRA を使用している場合に、ソフトウェアのクラッシュが発生すると、watchdog プロセスがゲートウェイ、Netlet プロキシ、およびリライタプロキシを自動的に再起動します。

ノーシングルポイント障害

Portal Server は、ノーシングルポイント障害 (NSPOF) シナリオを基本機能としてサポートします。NSPOF は、ベストエフォートシナリオをベースにし、それに加えてレプリケーションとロードバランスを採り入れています。

前述したとおり、構築モジュールは、Portal Server インスタンス、プロファイルの読み込みのための Directory Server マスターレプリカ、および検索エンジンのデータベースから構成されています。そのため、NSPOF を実現するには少なくとも 2 つの構築モジュールが必要であり、それによって構築モジュールのどちらかに障害が発生した場合のバックアップを提供します。これらの構築モジュールは、4 CPU × 8G バイト RAM で構成されます。

ロードバランサが Portal Server の障害を検出すると、ユーザーの要求をバックアップ構築モジュールにリダイレクトします。障害検出の正確さは、ロードバランス製品によって異なります。一部の製品は、サーバーのいくつかの機能領域に関係するサービス、たとえばサーブレットエンジンや JVM を検索することによってシステムの可用性を確認できます。特に、Resonate、Cisco、Alteon、およびその他のほとんどのベンダーソリューションを使用する場合は、ユーザーがサーバーの可用性のためのスクリプトを任意に作成できます。ロードバランサは Portal Server ソフトウェアの一部ではないので、サードパーティベンダーから個別に入手する必要があります。

マルチマスターレプリケーション (Multi-master replication、MMR) は、構築モジュール間で行われます。各ディレクトリで発生する変更は他のディレクトリにレプリケートされます。つまり、各ディレクトリがサプライヤとコンシューマの両方の役割を果たします。MMR については、『Directory Server 6 Deployment Guide』を参照してください。

構築モジュール間でのコンシューマレプリケーションを伴う、管理コンソールまたはポータルデスクトップを使用したプロファイルの変更を常に維持できるように、冗長性もディレクトリマスターにとって同じように重要です。Portal Server と Access Manager は、MMR をサポートします。NSPOF シナリオは、マルチマスター構成を使用します。この構成では、2 つのサプライヤが更新を受け入れること、互いに同期をとること、またすべてのコンシューマを更新することが可能です。コンシューマは、更新要求を両方のマスターに任せることができます。

SRA は、NSPOF を実現するために Portal Server と同様にレプリケーションとロードバランスを採用します。そのため、このシナリオでは 2 つの SRA ゲートウェイとプロキシのペアが必要になります。SRA ゲートウェイは、特定のタイムアウト値後、要求に対して Portal Server インスタンスが応答しない場合に、Portal Server インスタンスの障害を検出します。これが発生すると、HTTPS 要求はバックアップサーバーにルーティングされます。SRA ゲートウェイは、最初の Portal Server インスタンスが再び稼働するまで定期的に可用性を確認します。

NSPOF の高可用性シナリオは、ビジネスクリティカルな配備に適しています。しかし、このシナリオの高可用性の制限の一部は、ミッションクリティカルな配備の要件を満たさない場合があります。

透過フェイルオーバー

透過フェイルオーバーは、NSPOF シナリオと同じレプリケーションモデルを使用しますが、追加の高可用性機能があり、これによってエンドユーザーに透過なバックアップサーバーにフェイルオーバーが行われます。


注	Access Manager 製品は、セッション固定を実施するためにロードバランスを設定することを要求します。これは、特定のインスタンスに対するセッションを確立すると、ロードバランサはそのセッションのために常に同じインスタンスに戻る必要があります。ロードバランサは、セッション cookie にインスタンスの識別名をバインドすることによってこれを実現します。原則としては、障害が発生したインスタンスを終了したときに、そのバインドは再設定されます。セッション固定は、パフォーマンス上の理由からも推奨します。


注	一般に、各構築モジュール内の Directory Server インスタンスは、他の場所で実行されるマスターディレクトリのレプリカとして構成されます。ただし、マスターディレクトリを構築モジュールの一部として使用するのを妨げるものはありません。専用ノードでマスターを使用しても、ソリューションの可用性は向上しません。専用マスターは、パフォーマンスのために使用します。

図 5-5 は、透過フェイルオーバーのシナリオを示しています。4 CPU × 8G バイト RAM から構成される 2 つの構築モジュールを示しています。ロードバランスは、Portal Server の障害を検出し、構築モジュール内のバックアップ Portal Server に要求をリダイレクトする責任があります。構築モジュール 1 は、セッションをセッションリポジトリに格納します。クラッシュが発生した場合、アプリケーションサーバーは構築モジュール 1 が作成したセッションをセッションリポジトリから取得します。

セッションリポジトリは、アプリケーションサーバーソフトウェアで提供されます。Portal Server は、アプリケーションサーバーで稼働します。Portal Server は、HttpSession フェイルオーバーをサポートするアプリケーションサーバーで透過フェイルオーバーをサポートします。詳細は、付録 C 「Portal Server とアプリケーションサーバー」を参照してください。

セッションフェイルオーバーを使用すると、クラッシュ発生後にユーザーを再認証する必要はありません。また、ポータルアプリケーションは、セッションが固定されるという前提で、チェックポイントで使用するコンテキストデータを保存できます。AMConfig.properties ファイルで com.iplanet.am.session.failover.enabled property を true に設定することによって、セッションのフェイルオーバーを設定できます。

Netlet プロキシは、TCP プロトコルの制限により透過フェイルオーバーシナリオをサポートできません。Netlet プロキシは、TCP 接続をトンネルし、オープンな TCP 接続を別のサーバーに移すことはできません。Netlet プロキシのクラッシュによって、再確立する必要があるすべての未処理の接続がなくなります。

構築モジュールの制約

構築モジュールのスケーラビリティの制約は、プロファイルの更新によって生じる LDAP の書き込みの数と LDAP データベースの最大サイズによります。詳細は、「Directory Server の要件」を参照してください。

特定のサイトの分析結果が、LDAP の書き込み操作が実際に制約となっていることを示す場合は、この問題の解決策として、受信要求をポータルの適切なインスタンスに転送するディレクトリの特定の分岐とその前にある層のみをレプリケートする構築モジュールを作成することができます。

構築モジュールソリューションの配備

ここでは、構築モジュールソリューションを配備するためのガイドラインを説明します。

配備のガイドライン

構築モジュールの構築方法によってはパフォーマンスに影響します。構築モジュールを適切に配備するためには、次に示す推奨事項を考慮してください。

Directory Server の要件

構築モジュールを配備するための Directory Server の要件を確認します。Directory Server の配備の特定の情報は、『Directory Server Deployment Guide』を参照してください。

Portal Server の配備を計画する際には、次に示す Directory Server のガイドラインを考慮してください。


注	/tmp ディレクトリに _db ファイルがある場合に LDAP サーバーがクラッシュすると、サーバーが再起動するときにこのファイルは失われます。これはパフォーマンスを向上させますが、可用性にも影響します。

Directory Server コンシューマレプリカプロセッサセットに必要な CPU の量は、構築モジュールに含まれる Portal Server インスタンスの数、またパフォーマンスおよび容量の考慮事項によって決定されます。

可能であれば、1 つの Directory Server インスタンスを1 つの構築モジュール内の Portal Server インスタンス専用にします。図 5-2 を参照してください。

ディレクトリデータベースインデックス全体とメモリー内のキャッシュをマップして、ディスクの遅延に関する問題を防止します。

複数の構築モジュールを配備するときは、Directory Server サプライヤに対するプロファイルの更新とレプリケーションのオーバーヘッドによる障害を回避するためにマルチマスター構成を使用します。

検索エンジンの構造

検索エンジンを構築モジュールソリューションの一環として配備するときには、次の点を考慮してください。

各構築モジュールでは、1 つの Portal Server インスタンスだけの検索エンジンデータベースに RD が含まれているようにします。残りの Portal Server インスタンスの検索エンジンデータベースは、デフォルトの空の状態であるようにします。

ポータルの検索データベースに構築モジュールを使用するかどうかに影響する要素には、同時並行検索の数に加えて、Portal Server 配備の検索活動の程度、検索のヒットの範囲、すべてのユーザーの検索ヒットの平均数があります。たとえば、検索エンジンによるサーバーへの負荷は、大きなインデックスや高負荷のクエリーの場合はメモリーと CPU の両方をかなり使用することがあります。

検索機能を Portal Server とは別のマシンにインストールして、主なサーバーをポータルの活動専用にすることができます。そのようにする場合、検索プロバイダの searchURL プロパティを使用して、検索機能がインストールされた 2 番目のマシンを指すようにします。検索インスタンスは、通常のポータルインスタンスです。ポータルインスタンスをインストールするのと同様に検索インスタンスをインストールしますが、検索インスタンスは検索機能のみに使用します。

検索データベースのサイズによって、複数のマシンにまたは構築モジュールに検索データベースをレプリケートすることで複数のマシンが検索データベースをホストする必要があるかどうかが決まります。ハイエンドのディスクアレイを使用することを考慮します。

プロキシサーバーを使用して、検索ヒットの結果をキャッシュします。そのようにする場合、ドキュメントレベルのセキュリティを無効にする必要があります。ドキュメントレベルのセキュリティについては、『Portal Server 6 管理ガイド』を参照してください。

Portal の使用事例のシナリオの設計

使用事例のシナリオは、システムの能力をテストして示し、高レベルの設計の重要な部分を形成するために記述されたシナリオです。使用事例シナリオはプロジェクトの終わりの方で実現しますが、要件が定まったら、プロジェクトの早い段階でまとめておきます。

利用できる場合、使用事例はシステムをどのようにテストすべきかを判断する際に役立ちます。使用事例は、ユーザーインタフェースをどのように設計するかを、ナビゲーションの観点から決定する際に役立ちます。使用事例を設計する際には、使用事例を要件と比較して、使用事例の完成度、またテスト結果の解釈方法を判断します。

使用事例は、要件をまとめる手段にもなります。要件の一覧の代わりに、ユーザーがシステムをどのように使用できるかを説明するストーリーのように要件をまとめます。これにより完成度と一貫性が向上し、またユーザーの観点から見た要件の重要性について、さらに理解を深めることができます。

使用事例は、ポータルの機能要件を特定および明確にするために役立ちます。使用事例は、ユーザーとポータル間のやり取りのセット、またポータルが実行する必要があるサービス、タスク、および機能など、ポータルのさまざまな使い方をすべて網羅します。

使用事例は、外部のアクターとポータルシステム間の目的のあるやり取りのセットを定義します。アクターは、システムとやり取りするシステム外に存在するパーティーであり、ユーザーのクラス、ユーザーが担うことのできるロール、またはその他のシステムになります。

使用事例は、対象領域の用語を使用した、理解しやすい構造化された物語として記述されます。

使用事例のシナリオは、使用事例の 1 つの例であり、使用事例の 1 つの筋道を表します。したがって、使用事例の主な筋に対するシナリオ、また使用事例の起こりうるさまざまな筋 (たとえば、各オプションを表す) に対するシナリオを作成できます。

ポータルの使用事例の要素

ポータルの使用事例を開発する場合は、次に示す要素に注意してください。

優先順位: 使用例の優先順位、または順位を記述します。たとえば、これは「高」、「中」、「低」の範囲にすることができます。

使用の背景: 使用事例を実現する設定または環境を記述します。

範囲: 使用事例の条件および制限を記述します。

プライマリユーザー: これがあてはまるユーザーの種類、たとえば、エンドユーザーまたは管理者を記述します。

特別な要件: 適用されるその他の条件を記述します。

関係者: 製品の決定がどのように行われるか、または実行されるかに「利害関係」がある人々を記述します。

前提条件: 使用事例を実現するために満たす必要のある必要条件を記述します。

最小限の保証: 使用事例が成功しなかった場合に最低限行う必要があることを記述します。

成功の保証: 使用例が成功した場合に何が起きるかを記述します。

トリガー: イベントの発生の原因になる、システム内の特定のアイテムを記述します。

説明: 使用事例の、始めから終わりまでの、段階的な記述です。

使用事例の例: ポータルユーザーの認証

表 5-2 では、ポータルのユーザーがポータルに認証される使用事例について説明します。

表 5-2 使用事例: ポータルユーザーの認証
アイテム	説明
優先順位	必須です。
使用の背景	認証済みのユーザーのみがポータルのリソースにアクセスを許可されます。このアクセス制限は、コンテンツおよびサービスを含む、すべてのポータルのリソースに適用されます。このポータルは、企業の LDAP ディレクトリで管理されているユーザー ID を利用します。
範囲	ポータルユーザーは、完全なオンラインセッションのために 1 回だけ自分の身元を証明します。アイドルタイムアウトが発生する場合は、ユーザーは自分の身元を再度証明する必要があります。ポータルユーザーの身元証明の失敗回数が指定された許容再試行回数よりも多い場合、システム管理者がアカウントを再び有効にするまで、イントラネットへのアクセスは拒否または制限 (無効) される必要があります。この場合、ポータルのユーザーに、担当者に連絡するように勧める必要があります。身元が確認されたポータルユーザーは、許可されたデータおよび情報にだけアクセスできます。
プライマリユーザー	ポータルエンドユーザー。
特別な要件	なし。
関係者	ポータルエンドユーザー。
前提条件	ポータルユーザーは、承認されたユーザーです。標準的な企業 LDAP ユーザー ID。各従業員に提供する必要があります。承認された LDAP エントリ。すべての従業員が企業イントラネットにアクセスできます。ゲストアカウントなし。
最小限の保証	顧客主体の親切なメッセージ。ステータス - 誰に連絡するかを示すエラーメッセージ付き。
成功の保証	ポータルデスクトップのホームページを表示します。認証。権利の付与。個人情報。
トリガー	ポータルページがアクセスされときに、ユーザーがまだログインしていない場合。
説明	ユーザーがポータル URL を入力します。カスタマイズパラメータ [remember login] を設定した場合、ユーザーを自動的にログインさせ、セッション ID を提供します。初めてのユーザーの場合、LDAP ユーザー ID とパスワードの入力を要求します。ユーザーは、事前に割り当てられたユーザー ID とパスワードを入力します。情報は検証のために Access Manager に渡されます。認証に成功した場合、セッション ID を割り当て、続行します。認証に失敗した場合、エラーメッセージを表示してユーザーをログインページに戻し、残りの試行回数を減分します。事前に設定された試行回数の制限を超えた場合、ユーザーに通知してアカウントをロックアウトします。

ポータルセキュリティの設計方針

セキュリティとは、サーバーおよびそのユーザーを悪意のある外部の者から保護するハードウェア、ソフトウェア、運用方法、および技術の集合のことです。それに関連して、セキュリティは予期しない行為から保護します。

セキュリティには、グローバルに対処し、ユーザーやプロセスだけでなく製品や技術も含める必要があります。あいにく、多くの組織が、唯一のセキュリティ方針としてファイアウォール技術のみに依存しています。それらの組織は、多くの攻撃は外部の者ではなく、従業員によるものであることに気づいていません。したがって、安全なポータル環境を構築するときには他のツールやプロセスを考慮する必要があります。

安全な環境で Portal Server を稼働させるには、Solaris^TM オペレーティング環境、ゲートウェイとサーバーの設定、ファイアウォールのインストール、および Directory Server による認証と Access Manager による SSO に対して特定の変更を行う必要があります。また、証明書、SSL 暗号化、グループおよびドメインアクセスを使用できます。

オペレーティング環境の保護

「システムの強化」とよく呼ばれる次のことを実行して、オペレーティング環境におけるセキュリティ侵害の可能性を削減します。

プラットフォームセキュリティの使用

通常は Portal Server を信頼できるネットワークにインストールします。ただし、このような安全な環境でも、それらのサーバーのセキュリティには特別な注意が必要です。

UNIX ユーザーのインストール

次に示す 3 種類の UNIX ユーザー下に Portal Server をインストールおよび構成できます。

root: これはデフォルトのオプションです。すべての Portal Server コンポーネントは、システムスーパーユーザーとして実行されるようにインストールおよび設定されます。この設定では、次のようなセキュリティの問題が生じます。

アプリケーションのバグを利用して、システムに root アクセスが可能です。

一部のテンプレートを変更するのに、root アクセスが必要になります。これは、システムを脅かす可能性があるシステム管理者でないユーザーにこの権限が通常付与されることになるので、セキュリティの問題になる可能性があります。

ユーザー nobody: Portal Server をユーザー nobody (uid 60001) としてインストールできます。ユーザー nobody には何の権限もないため、システムファイルを作成、読み取り、あるいは変更することはできないので、システムのセキュリティを向上できます。この機能は、ユーザー nobody が Portal Server を使用してシステムファイルにアクセスし、システムに侵入するのを防止します。

アクセス制御の制限

従来の UNIX のセキュリティモデルは通常、絶対的ですが、代替ツールを使用していくらか柔軟にできます。それらのツールは、異なる UNIX コマンドなどの個々のリソースに対するきめ細かなアクセス制御を可能にするために必要な手段になります。たとえば、このツールセットは、Portal Server を root として稼働させるのを可能にし、また特定のユーザーおよびロールに Portal Server フレームワークの起動、停止、および維持のためのスーパーユーザー権限を与えます。

非武装ゾーン (DMZ) の使用

最高のセキュリティを実現するには、2 つのファイアウォール間の DMZ にゲートウェイをインストールします。もっとも外側のファイアウォールはインターネットからゲートウェイへの SSL トラフィックのみを通し、次にゲートウェイがトラフィックを内部ネットワークのサーバーへ転送します。

異なるノードにある Portal Server と Access Manager

Portal Server と Access Manager は異なるノードに置くことができます。このタイプの配備には、次の利点があります。

Access Manager SDK は、次のコンポーネントから構成されています。


注	Portal Server と Access Manager を異なるノードに置く場合、Access Manager SDK は Portal Server と同じノードに存在する必要があります。Web アプリケーションとサポートする認証デーモンは、Portal Server インスタンスとは別のノードに置くことができます。

アイデンティティ管理 SDK: ユーザー、ロール、グループ、コンテナ、組織、組織単位、およびサブ組織を作成および管理するための枠組みを提供します。

認証 API および SPI: 認証サービスのすべての機能へのリモートアクセスを可能にします。

ロギング API および SPI: 数ある中でも、アクセスの承認、アクセスの拒否、およびユーザーの活動を記録します。

クライアント検出 API: リソースへアクセスしようとしているクライアントのブラウザのタイプを検出し、適切にフォーマットされたページで応答します。

SSO API: セッショントークンの検証と管理のインタフェース、またユーザー認証のクレデンシャルを管理するインタフェースを提供します。

ポリシー API: Access Manager のポリシーを評価および管理し、ポリシーサービスの追加機能を提供します。

SAML API: 認証、承認決定、および属性の情報を交換します。

連携管理 API: Liberty Alliance Project 仕様に基づいた機能を追加します。

図 5-6 は、別々のノードに存在する Access Manager と Portal Server を示しています。

Portal Server と Access Manager を分けて実装すると、次の 3 つの図が示すようなポータルサービスアーキテクチャの配備に対する他のトポロジの並びが可能になります。

図 5-7 は、1 つの Access Manager および 2 つの Directory Server と機能するように構成された 2 つの Portal Server インスタンスを示しています。ここでは、Access Manager と Directory Server の両方が Java Enterprise System Sun Cluster 環境で動作します。この構成は、Access Manager インスタンスと Directory Server インスタンスが障害でない場合に理想的です。

図 5-9 は、水平方向のサーバーファームによって実現された最大の水平方向のスケーラビリティと、より高い可用性の構成を示しています。最大のスループットと高可用性の実現のために、2 つの Portal Server の前にロードバランサを置くことができます。

別のロードバランサを、Portal Server と Access Manager の間に置いて、認証プロセスとポリシープロセスが高可用性のための負荷の分散とフェイルオーバーの手段となるようにできます。

このシナリオでは、Portal サービスに Blade 1500s を利用して負荷を分散し、これと似た Blade を使用して Access Manager サービスと Directory サービスのそれぞれをホストできます。図 5-9 に示されたアーキテクチャでは、製品スタックのそれぞれに冗長のサービスが存在するので、計画外の停止時間を最小限に、またはなくすことができます。

ただし、予定された停止時間は依然問題になります。アップグレードまたはパッチに Access Manager ソフトウェアが使用する Directory Server ソフトウェアスキーマの変更が含まれる場合、Directory Server に格納されたスキーマ情報を更新するためにこのソフトウェアのすべてのコンポーネントを停止する必要があります。ただし、スキーマ情報の更新は、ほとんどのパッチアップグレードではめったに発生しないとみなすことができます。

Portal Server と Access Manager のサーバーの 2 つのインスタンスが同じ LDAP を共有している場合、後続のすべての Portal Server、Access Manager、およびゲートウェイについて次のように対処します。

/etc/opt/SUNWam/config/ums では、Portal Server と Access Manager のサーバーに最初にインストールされたインスタンスと同期するように、serverconfig.xml 内の次の領域を変更します。

<DirDN>

cn=puser,ou=DSAME Users,dc=sun,dc=net

</DirDN>

AQICxIPLNc0WWQT22gQnGgnCp9rUf+FuaqpY <== この文字列を、当初のポータルのインストール内容に置き換えてください。

</DirPassword>

<DirDN>

cn=dsameuser,ou=DSAME Users,dc=sun,dc=net

</DirDN>

AQICxIPLNc0WWQT22gQnGgnCp9rUf+FuaqpY <== この文字列を、当初のポータルのインストール内容に置き換えてください。

</DirPassword>

amserver サービスを再起動します。

SRA の配備シナリオの設計

SRA ゲートウェイは、インターネットから送信されるリモートユーザーセッションと企業イントラネットの間のインタフェースおよびセキュリティバリアとして機能します。ゲートウェイには、次の 2 つの主な機能があります。

インターネットアクセスの場合、128 ビット SSL を使用して、ユーザーのブラウザと Portal Server 間の最高のセキュリティ対策と暗号化、または通信を実現します。ゲートウェイ、Netlet、NetFile、Netlet プロキシ、リライタプロキシ、および Proxylet が SRA の主なコンポーネントです。

ここでは、それらのコンポーネントの可能な構成をいくつか示します。業務のニーズに基づいて正しい構成を選択してください。このセクションでは、指針を示すだけで、完全な配備の参考情報を提供するわけではありません。

基本 SRA 構成


ヒント	authlessanonymous ページをゲートウェイ経由で表示するように設定するには、ゲートウェイプロファイルの非認証 URL に /portal/dt を追加します。ただし、これは、普通のユーザーの場合でも、ポータルページは認証を必要とせず、セッションの検証が実行されないことを意味します。

図 5-10 は、SRA のもっとも単純な構成を示しています。この図では、クライアントのブラウザが NetFile および Netlet を実行しています。ゲートウェイは、2 つのファイアウォールの間の DMZ 内の個別のマシンにインストールされています。Portal Server は、イントラネット内の 2 番目のファイアウォールの外側に置かれています。クライアントがアクセスする他のアプリケーションホストも、イントラネット内の 2 番目のファイアウォールの外側に置かれています。

ゲートウェイは、DMZ 内にあり、ファイアウォール内の開いた外部ポートを通してクライアントのブラウザがゲートウェイと通信します。2 番目のファイアウォールでは、HTTP または HTTPS トラフィックのために、ゲートウェイは内部ホストと直接通信できます。セキュリティポリシーがこれを許可しない場合は、ゲートウェイと内部ホストとの間に SRA プロキシを使用します。Netlet トラフィックの場合、ゲートウェイから目的のホストへの直接接続になります。

SRA プロキシを使用しない場合、SSL トラフィックはゲートウェイに制限され、ゲートウェイと内部ホスト間ではトラフィックは暗号化されません (内部ホストが HTTPS モードで実行されていないかぎり)。内部ホストに対してゲートウェイが Netlet 接続を開始する必要がある内部ホストは、DMZ から直接アクセス可能である必要があります。これはセキュリティの問題になる可能性があるので、この構成はもっとも単純なインストールにのみ推奨します。

Netlet の無効化

図 5-11 は、Netlet が無効ということ以外は基本 SRA 構成と同様のシナリオを示しています。クライアントの配備がイントラネットと通信する必要があるアプリケーションを安全に実行するために Netlet を使用しない場合は、パフォーマンス向上のためにこの構成を使用します。

この構成を拡張して、他の配備シナリオと組み合わせて、パフォーマンスを向上し、拡張可能なソリューションを提供できます。

ホスト

図 5-12 で示すプロキシレットは、イントラネットのリソースをクライアントに公開しなくても、ユーザーがインターネットを使用してイントラネットのリソースに安全にアクセスできるようにします。

プロキシレットでは、ゲートウェイのトランスポートモード (HTTP または HTTPS のどちらか) が継承されます。

複数のゲートウェイインスタンス

図 5-13 は、SRA の基本構成の拡張を示しています。複数のゲートウェイインスタンスが、同じマシンまたは複数のマシンで稼働します。別々のプロファイルで複数のゲートウェイインスタンスを起動できます。詳細は、『Portal Server Secure Remote Access 6 管理ガイド』の第 9 章「ゲートウェイの設定」を参照してください。

この構成の欠点は、各接続要求のために 2 番目のファイアウォールで複数のポートを開く必要があるということです。これは、セキュリティの問題になる可能性があります。

Netlet プロキシとリライタプロキシ


注	図 5-13 はゲートウェイと Portal Server の 1 対 1 の対応を示していますが、実際の配備では必ずしもこのようになる必要はありません。複数のゲートウェイインスタンスや複数の Portal Server インスタンスを配備可能であり、また構成によってはどのゲートウェイも任意の Portal Server にアクセスできます。

図 5-14 は、イントラネットに Netlet プロキシとリライタプロキシがある構成を示しています。これらのプロキシの場合、2 番目のファイアウォールではポートが 2 つだけ開いている必要があります。

この構成では、ゲートウェイはアプリケーションホストと直接やり取りする必要はありませんが、すべての Netlet トラフィックを Netlet プロキシへ、リライタトラフィックをリライタプロキシへ転送します。Netlet プロキシはイントラネット内にあるので、2 番目のファイアウォールで複数のポートを開かなくても、すべての必要なアプリケーションホストと直接やり取りできます。

DMZ 内のゲートウェイと Netlet プロキシとの間のトラフィックは暗号化され、Netlet プロキシでのみ復号化されるので、セキュリティが向上します。

リライタプロキシが有効な場合、要求が Portal Server ノード宛てのものかどうかにかかわらず、すべてのトラフィックがリライタプロキシに転送されます。これによって、DMZ 内のゲートウェイからイントラネットへのトラフィックは常に暗号化されることが保証されます。

Netlet プロキシ、リライタプロキシ、および Portal Server がすべて同じノードで稼働するので、そのような配備シナリオではパフォーマンスの問題が発生する場合があります。この問題は、Portal Server ノードの負荷を軽減するためにプロキシを別々のノードにインストールすると解決できます。

別々のノードにある Netlet プロキシとリライタプロキシ

Portal Server ノードの負荷を軽減し、なおかつパフォーマンスを向上させて同じレベルのセキュリティを提供するには、Netlet プロキシとリライタプロキシを別々のノードにインストールできます。この配備は、プロキシを使用して Portal Server を DMZ から保護できるというさらなる利点があります。これらのプロキシを実行するノードは、DMZ から直接アクセス可能である必要があります。

図 5-15 は、別々のノードにある Netlet プロキシとリライタプロキシを示しています。ゲートウェイからのトラフィックは別のノードに転送され、そのノードはトラフィックをプロキシ経由で、必要なイントラネットのホストに転送します。

Netlet プロキシとリライタプロキシの複数のインスタンスを持つことや複数の Netlet プロキシとリライタプロキシをインストールすることが可能です。各ゲートウェイを、可用性に応じてラウンドロビン方式でプロキシのさまざまなインスタンスとのやり取りを試みるように設定できます。

2 つのゲートウェイと Netlet プロキシの使用

ロードバランサは、Portal Server および Access Manager の冗長サービスの高可用性のためのフェイルオーバーのメカニズムを提供します。

アクセラレータの使用

外部の SSL デバイスをオープンモードでゲートウェイの前で実行するように設定できます。これは、クライアントと SRA の間に SSL リンクを提供します。アクセラレータの詳細は、『Portal Server Secure Remote Access 6 管理ガイド』を参照してください。

サードパーティのプロキシを使用する Netlet

図 5-18 は、サードパーティのプロキシを使用して、2 番目のファイアウォールのポートの数を 1 つに制限する例を示しています。サードパーティのプロキシを使用して、リライタプロキシまたは Netlet プロキシに到達するようにゲートウェイを設定できます。

逆プロキシ

プロキシサーバーがインターネットのコンテンツをイントラネットに配信するのに対して、逆プロキシサーバーはイントラネットのコンテンツをインターネットに配信します。逆プロキシの特定の配備の際に、インターネットコンテンツのロードバランスおよびキャッシングが行われるように設定できます。

図 5-19 は、インターネットとイントラネットの両方のコンテンツを承認されたユーザーに配信するために、ゲートウェイの前に逆プロキシを配置する方法を示しています。ゲートウェイが Web コンテンツを配信するときには、このコンテンツに基づいた後続するブラウザの要求すべてがゲートウェイを通じてルーティングされるようにする必要があります。これは、このコンテンツ内のすべての URL を確認し、必要に応じて書き換えることによって実現します。

地域化の設計

地域化とは、テキストおよび文化的な内容を特定の対象者向けに適合させる処理のことです。地域化には、次の 2 つの方法で取り組むことができます。

高度な言語の地域化の場合、テンプレートのディレクトリのために正しく定義されたディレクトリ構造を作成します。

アップグレードパスを保つには、カスタムコンテンツとカスタムコードをデフォルトのディレクトリ外に保持します。地域化については、『Portal Server 6 Developer不 Guide』を参照してください。

コンテンツと設計の実装

ポータルデスクトップは、Portal Server のプライマリエンドユーザーインタフェースであり、プロバイダアプリケーションプログラミングインタフェース (PAPI) による広範なコンテンツ集約のメカニズムを備えています。ポータルデスクトップには、コンテナ階層と、特定のチャネルを構築するための基本構築ブロックとを有効にするさまざまなプロバイダが表示されます。コンテンツプロバイダとチャネルデータを保存する場合、ポータルデスクトップは Access Manager サービスのトップでディスプレイプロファイルデータ保管メカニズムを実行します。

コンテンツの集約に使用できるさまざまな技術を次に示します。

詳細は、『Portal Server 6 Developer不 Guide』と『Portal Server 6 Desktop Customization Guide』を参照してください。

静的なポータルコンテンツの配置

静的なポータルコンテンツは、web-container-install-root/SUNWam/public_html ディレクトリまたは web-container-install-root/SUNWam/public_html ディレクトリ (Web コンテナのドキュメントルート) 下のサブディレクトリに配置します。web-container-install-root/SUNWps/web-apps/https-server/portal/ ディレクトリは非公開のディレクトリであるため、コンテンツをこのディレクトリに配置しないでくさい。このディレクトリに配置されたコンテンツは、パッチまたはその他の更新時に Portal Server の Web アプリケーションが再配備されたときに削除の対象になります。

統合の設計

ここでは、低レベルの設計で考慮する必要がある統合関連の情報を提供します。

カスタム Access Manager サービスの作成

Access Manager のサービス管理は、Access Manager サービスとして属性のグループを定義、統合、および管理する手段になります。管理のためにサービスを準備するには、次の手順が伴います。

詳細については、Access Manager のマニュアルを参照してください。

アプリケーションの統合

アプリケーションの Portal Server との統合および配備は、配備作業の中でも、もっとも重要な作業の 1 つです。アプリケーションのタイプを次に示します。

チャネル: 限定されたコンテンツオプションを提供します。「ミニブラウザ」ではありません。

ポートレット: ポータルのコンテキストの範囲内で要求を処理し、コンテンツを生成する、プラグイン可能な Web コンポーネント。Portal Server ソフトウェアでは、ポートレットコンテナがポートレットを管理します。概念的には、ポートレットはプロバイダと同等です。

ポータルアプリケーション: ポータルアプリケーション専用のブラウザウィンドウ内のチャネルから起動されます。Portal Server は、Access Manager サービスとして作成された NetMail などのアプリケーションをホストします。また、Portal API と Access Manager API にアクセスします。

サードパーティのアプリケーション: Portal Server とは別にホストされますが、Portal Server からアクセスされます。リライタを呼び出す URL スクレイパーは、チャネルに表示できるように Web ページを書き換えます。Access Manager を使用してシングルサインオンを有効にします。

独立ソフトウェアベンダー

次に独立ソフトウェアベンダー (ISV) の統合機能のいくつかのタイプを示します。

アプリケーションのユーザーインタフェース: この統合機能は、安全なアクセスのためにプロバイダの API と SRA を使用します。SRA は単独では統合タイプではありません。たとえば、FatWire、Interwoven、SAP、Tarantella、Documentum、Vignette、PeopleSoft、Siebel、Citrix、YellowBrix などがあります。

セキュリティ製品: この統合機能は、Access Manager の Login API を使用して、カスタム認証スキームを使用したポータルアクセスを有効にます。たとえば、RSA などがあります。

コンテンツの管理: この統合機能は、Portal Server へのデータアクセスを提供し、データの検索を可能にします。たとえば、FatWire、Interwoven、Vignette などがあります。

コンテンツのシンジケート: この統合機能は、Web サイトに表示される情報の管理およびカスタマイズを行います。たとえば、YellowBrix、Pinnacor などがあります。

コラボレーションソフトウェア: この統合機能は、Sun Java System Instant Messaging 製品がコラボレーションセッションを 1 つのフォーラムから別のフォーラムに移すことを可能にします。たとえば、WebEx、BeNotified、Lotus などがあります。

監視: この統合機能は、課金、パフォーマンスの測定、および診断に的を絞り、このためにログファイル (または Access Manager の Logging API) およびトラフィックの snooping を利用します。たとえば、Mercury Interactive、Hyperion、Informatica などがあります。

ポータルの機能の拡張: この統合機能は、製品が Portal Server に機能を追加することを可能にします。たとえば、Altio、Bowstreet、グループ機能を追加するルールエンジン、ダイナミックな標準のポータルデスクトップおよびプロバイダコンテンツ (HNC) などがあります。

統合可能なポータルスタック: この統合機能には、Portal Server の要素を置き換える製品が含まれています。たとえば、Access Manager、LDAP などがあります。



注	Portal Server は現在別の LDAP ソリューションを統合できません。Access Manager と Portal Server は、他の LDAP 実装にない機能を利用します。

Portal Server とユーザーインタフェースの統合が行われる「深さ」は、統合がどの程度完了したかを示します。深さは、統合の補完的な性質を説明するために使用する用語であり、次のようなアイテムを指します。

一般に、アプリケーションが Portal Server と統合する程度は、次のように見なすことができます。

Microsoft Exchange の統合

JavaMail^TM API の使用は、Microsoft Exchange メッセージングサーバーを Portal Server と統合する主なオプションの 1 つです。JavaMail API は、Java テクノロジに基づいたメールおよびメッセージングアプリケーションを構築するためのプラットフォーム独立およびプロトコル独立フレームワークです。JavaMail API は、Java プラットフォームのオプションのパッケージとして実装され、Java^TM 2 Platform, Enterprise Edition の一部としても利用できます。

JavaMail は、メールを管理するための共通の統一 API を提供します。JavaMail は、サービスプロバイダが Java プログラミング言語を使用して標準ベースのまたは独自のメッセージングシステムへの標準のインタフェースを提供するのを可能にします。この API を使用して、アプリケーションはメッセージストアにアクセスし、メッセージを作成および送信できます。

アイデンティティとディレクトリ構造の設計

ポータルの実装の主な部分は、ディレクトリ情報ツリー (DIT: Directory Information Tree) の設計です。DIT は、ユーザー、組織、サブ組織などを論理構造または階層構造に編成することにより、管理を効率的に行い、適切なアクセス権限をユーザーに割り当てることを可能にします。

Access Manager の組織ツリーの最上位は、デフォルトで dc=fully-qualified-domain-name と呼ばれ、インストール時に変更または指定できます。インストール後に、追加の組織を作成して、別の企業を管理することができます。作成された組織はすべて最上位組織の下に配置されます。これらのサブ組織内で、他のサブ組織を入れ子にできます。入れ子の構造の深さには制限がありません。

ロールは、より効果的に、またより簡単にアプリケーションを使用するように設計されたグループ化メカニズムです。それぞれのロールはメンバー、あるいはロールを保有するエントリを持ちます。グループの場合と同じく、ロールのメンバーは明示的またはダイナミックに指定できます。


注	ツリーの最上位を dc と呼ぶ必要はありません。必要に応じてこの名前を変更できます。ただし、たとえば、dc など一般的な最上位で編成されたツリーでは、ツリー内の組織はロールを共有することができます。

ロールメカニズムにより、そのエントリがメンバーになっているすべてのロール定義の識別名 (Distinguished Name、DN) を含む nsRole 属性が自動的に生成されます。各ロールは、1 人または複数のユーザーに付与できる、単一の権限や権限のセットを含んでいます。複数のロールを 1 人のユーザーに割り当てることができます。

ロールの権限はアクセス制御命令 (ACI) で定義されます。Portal Server には、いくつかのロールが事前に定義されています。Access Manager 管理コンソールを使用してロールの ACI を編集し、ディレクトリ情報ツリー内でアクセス権を割り当てることができます。用意されている例には、SuperAdmin Role および TopLevelHelpDeskAdmin が含まれます。組織間で共有できるその他のロールを作成することもできます。

Access Manager および Directory Server 構造の計画については、『Portal Server 6 管理ガイド』、『Directory Server Deployment Guide』、および『Access Manager Deployment Guide』を参照してください。

シングルサインオンの実装

Portal Server へのシングルサインオン (Single sign-on、SSO) は、Access Manager によって管理されます。SSO は、ポリシーによって許可される場合、Access Manager によってアクセスポリシーが管理されるアプリケーションをユーザーが使用できるようにします。ユーザーは、そのアプリケーションに再認証される必要はありません。

ポータル Web アプリケーション: 認証は Access Manager から行われ、アプリケーションは Access Manager によってユーザーのクレデンシャルを検証します。

スタンドアロン Web アプリケーション: アプリケーションは別の Web コンテナでホストされ、Access Manager Web Agent は Access Manager による認証で使用されます。これには、アプリケーションのコーディングは必要ありません。さらに、Access Manager に対して直接検証を行うようにアプリケーションを変更できます。

スタンドアロン Java アプリケーション: このシナリオでは、ユーザーのクレデンシャルを Access Manager に対して直接検証を行うようにアプリケーションを変更します。

非 Access Manager 対応アプリケーション: このシナリオでは、アプリケーションはユーザーのクレデンシャルを保存し、必要に応じて提供します。ただし、クレデンシャルが変更される場合はユーザーが再認証を行う必要があるので、これは理想的な SSO ソリューションではありません。

ポータルデスクトップの設計

Portal Server そのもののパフォーマンスは、個々のチャネルの実行速度によって決定されます。また、ポータルに対するユーザーの体感は、ポータルデスクトップが表示される速度に基づきます。ポータルデスクトップは、最低の速度で表示されるチャネルと同じ速度でのみ読み込みを行うことができます。たとえば、10 個のチャネルから構成されるポータルデスクトップを考えてみます。9 つのチャネルが 1 ミリ秒で描画されるが、10 番目のチャネルが 3 秒かかる場合は、ポータルデスクトップはポータルが 10 番目のチャネルを処理するまで表示されません。各チャネルが要求を最短時間で処理できるようにすることによって、ポータルデスクトップのパフォーマンスの向上を実現できます。

正しい集約方針の選択と実装

速度とスケーラビリティの向上を目的としてポータルチャネルを実装するために選択できるいくつかの方法を次に示します。

ポータルサーバーではなく、バックエンドシステムおよびアプリケーションサーバーに処理機能を置きます。ポータルサーバーは、ユーザーからの要求の取得を最適化する必要があります。できるかぎり多くのビジネスロジック処理をバックエンドシステムに任せます。可能なかぎり、カスタマイズしたコンテンツを処理するためではなく、ユーザーに配信するためにポータルを使用します。

バックエンドシステムが高度にスケーラブルでパフォーマンスがよい状態になるようにします。ポータルデスクトップは、(チャネルで表示する) 情報の入手先のサーバーと同程度の速度で応答します

プロバイダを設計する際には、データの格納場所、ポータルがデータを入手する方法、プロバイダがデータを入手する方法、およびデータのタイプを理解します。たとえば、データが個々のユーザーに関係する動的なデータであるか、あるいはカスタマイズされたまたはパーソナライズされたデータを取得するのにコードが必要かどうかなどです。また、データが静的であり、小さなグループのユーザーによって共有されるかなどです。次に、データの存在場所 (たとえば、XML ファイル、データベース、フラットファイルなど) とデータの更新の頻度を理解する必要があります。最後に、プロバイダがパーソナライズされたチャネルをユーザーに配信できるように、データの処理にどのようにビジネスロジックが適用されるかを理解する必要があります。

プロバイダの操作

プロバイダの配備を計画するときには、次のことを考慮します。

URLScraperProvider は、ページを取得するたびにある程度の書き換えも実行します。たとえば、チャネルが別の Web サイトにホストされている写真を含むニュースのページを取得する場合、ポータルがその写真を表示できるようになるには、その写真の URL を書き換える必要があります。ポータルはその写真をホストしていないので、URLScraperProvider はポータルのユーザーに表示するためにその写真を書き換える必要があります。

Portal Server の一部である URL スクレイパープロバイダは、ファイルスクレイパープロバイダとしても機能します。

URLScraperProvider をファイルスクレイパープロバイダとして使用するには、次のように URL を指定します。

String name="url" value="file://path/filename"

コンテンツの取得速度の観点から見ると、このプロバイダはもっとも優れているプロバイダです。コンテンツの最初の取得では、このプロバイダのパフォーマンスは通常 13 ～ 15 ミリ秒程度になります。それ以降の要求に、組込みのキャッシュメカニズムを使用すると、このプロバイダは通常 1 ミリ秒以下でコンテンツを配信できます。適用可能な場合、URL スクレイパープロバイダの代わりにファイルスクレイパープロバイダを使用することを考えてみます。

JSPProvider: JavaServer Pages^TM (JSP) 技術を使用します。JSPProvider は、1 つまたは複数の JSP ファイルからコンテンツを取得します。JSP ファイルは、静的なドキュメント (HTML のみ)、または HTML および Java プログラミング言語からなる標準の JSP ファイルにすることができます。JSP ファイルには別の JSP ファイルを含めることができます。ただし、最上位の JSP ファイルのみをディスプレイプロファイルによって設定できます。最上位の JSP ファイルは、contentPage、editPage、および processPage プロパティによって定義されます。

LoginProvider: ポータルデスクトップチャネルによって、Access Manager の認証サービスへのアクセスを提供します。このプロバイダは、ユーザーがポータルデスクトップから直接ログインできるように、匿名ポータルデスクトップログインを可能にします。

XMLProvider: XSLT (XML Style Sheet Language) ファイルを使用して、XML ドキュメントを HTML に変換します。XML ドキュメントタイプに一致する適切な XSLT ファイルを作成する必要があります。XMLProvider は、URLScraperProvider を拡張したものです。このプロバイダは、Web Server が提供する JAXP 1.2 JAR ファイルを使用します。

LDAP ベースのプロバイダ: このタイプのプロバイダは、ユーザーおよびパーソナライズの適用についての情報をユーザープロファイルから取得します。このプロバイダは、格納された LDAP 属性の数が少ない間は効率的です。一般に、このタイプのプロバイダのパフォーマンスは良く、URLScraperProvider 内で提供されるファイルスクレイパープロバイダに次ぐパフォーマンスを提供します。

データベースプロバイダ: このタイプのプロバイダは、そのコンテンツにバックエンドデータベースを利用します。このプロバイダは、データベース接続ポーリングを作成し、少数のクエリー (1 つまたは 2 つのクエリー) を使用することを要求します。また、HTML のフォーマットのために余分な作業を実行する必要がある場合があります。一般に、データベース接続ポーリング、大きなデータベースクエリー、不良コーディング、または取得されたデータにインデックスが作成されていないなどの原因により、このタイプのプロバイダのパフォーマンスはもっとも低くなります。さらに、データを取得すると、ポータルはデータをポータルデスクトップに表示するために大量の処理を実行する必要があります。このタイプのプロバイダを使用する場合、データ処理ロジックをできる限りデータベースに任せます。また、データベースチャネルがある状態とない状態でポータルのパフォーマンスを測定してユーザープロファイルに記録します。

クライアントのサポート

Portal Server は次のブラウザをクライアントとしてサポートします。

最新のリストは、『Portal Server 6 リリースノート』を参照してください。

HTML、WML、またはその他のプロトコルのどれに基づいていようと、複数のクライアントタイプが、Access Manager に、またその結果 Portal Server にアクセスできます。この機能を有効にするには、Access Manager はクライアント検出サービス (クライアント検出 API) を使用してポータルにアクセスするクライアントのタイプを検出します。次に、そのクライアントタイプを使用して、出力に使用するポータルテンプレート、JSP ファイル、および文字エンコーディングを選択します。

Sun Java System Portal Server Mobile Access 6.3 ソフトウェアは、Portal Server プラットフォームのサービスと機能をモバイルデバイスへ拡張し、音声アクセスのためのフレームワークを提供します。このソフトウェアは、HTML ブラウザを使用してアクセスする場合と同じコンテンツをポータルサイトのユーザーが入手できるようにします。

Mobile Access ソフトウェアは、xHTML、cHTML、HDML、HTML、WML などのモバイルマークアップ言語をサポートします。このソフトウェアは、HTTP または HTTPS のどちらかのプロトコルを使用して、LAN または WAN 経由でワイヤレスネットワークに接続されているモバイルデバイスをサポートできます。実際に、Portal Server Mobile Access ソフトウェアは、オートモバイル、セットトップボックス、PDA、携帯電話、音声など任意の数のデバイスをサポートできます。

前へ目次索引次へ
Sun Java System Portal Server 6 2005Q1 配備計画ガイド


注	現在、Access Manager は、Internet Explorer や Netscape Communicator などのサポートされている HTML クライアントブラウザに対するクライアントデータのみを定義します。詳細については、Access Manager のマニュアルを参照してください。