|
|
この章では、連合ポータルについて簡単に説明すると共に、連合ポータルを使う利点や連合ポータルによって解決できる問題について取り上げます。この章の内容は以下のとおりです。
連合ポータルとは、リモートのポートレット、ブック、ページなど、離れた場所に分散されたリソースを含むポータルを指します。これらのリモートのリソースは、コンシューマと呼ばれるポータル アプリケーションで実行時に収集および結合されます。連合ポータルは、このコンシューマによってエンド ユーザに表示されます。多くの場合、連合ポータルに含まれるリモートの各要素は、連合されない完全にローカルなポータルと異なり、表示されるコンシューマ ポータルを再度デプロイすることなく、個別に保持、更新、およびリリースできます。
図 2-1 に、連合ポータルの基本部分、つまりプロデューサとコンシューマを示します。プロデューサは、コンシューマという他のポータル Web アプリケーションにリモート ポートレットを提供するポータル Web アプリケーションです。プロデューサとコンシューマの両方が、通信を可能にする Web サービス レイヤを実装します。この Web サービス レイヤを使用すると、プロデューサはリモート システム上のコンシューマにポートレットを提供できます。コンシューマは、この分散したリモート ポートレットを実行時にまとめます。リモート ポートレット自体は、別のグループのユーザが開発および保持できます。プロデューサ上のあるリモート ポートレットが変更されても、更新されたポートレットを使用するコンシューマ内の他のポートレットは、通常は影響を受けません。また、リモート ポートレットのルック アンド フィールは、リモート ポートレットが存在する連合ポータルと統一できます。連合ポータルのエンド ユーザにとっては、リモート ポートレットはローカル ポートレットと区別ができません。
| ヒント : | 連合ポータルは、サービス指向アーキテクチャ (SOA) を忠実に反映しています。BEA では SOA を、「エンタープライズ アプリケーションに含まれている分散機能を、ビジネス ニーズに合わせて組み合わせてすばやく再利用できるように相互運用が可能な標準ベースのサービスにまとめる技術」と定義しています。SOA のこの定義は、連合ポータルの本質を適確に説明しています。 |
このガイドを通してリモート ポートレットという用語は、コンシューマ アプリケーションにデプロイされるポートレットおよびプロデューサ アプリケーションにデプロイ済みのポートレットを参照するポートレットを示しています。リモート ポートレットに対応する別の用語はプロキシ ポートレットです。プロキシ ポートレットという用語は、一部の WebLogic Portal コンフィグレーション ファイルで使用されます。リモート ポートレットとプロキシ ポートレットは同じ意味になります。連合環境では、プロデューサが、稼動しているポートレットをホストし、コンシューマ アプリケーションがプロキシ ポートレットをホストします。
連合前、ポータルのポートレットはすべて同じ Web アプリケーション内にデプロイされていました。このモデルは、ポータルの初期デプロイメントでは問題ありませんが、図 2-2 に示すように、ポータルが大きくなるとそれに比例して保守労力も増大します。
一般的なポータル保守には、バグ フィックス、拡張機能、新しいポートレットの追加、テスト、および開発からステージング、プロダクション環境への伝播などが含まれます。大規模なポータルほど含まれるパーツ、コードも単純に増えます。これらは、同じポータル アプリケーション内にバインドする必要があり、開発者、品質保証エンジニア、管理者、その他の関係者それぞれで更新が必要になります。多くの組織で、このような保守コストは甚大な額に上るだけでなく、保守のためにポータルを停止する場合もあります。連合によって、ポータルの保守が簡素化されます。
連合ポータル アーキテクチャでは、地理的に離れた場所の別々の開発チーム、たとえば、異なる事業単位がそれぞれのポートレットに集中して開発できます。これらの開発チームは、互いに関係なくそれぞれのポートレットを更新、テスト、リリースできます。プロデューサにデプロイされているポートレットが変更されるたびに、連合ポータルを毎回再デプロイする必要はありません。プロデューサでリモート ポートレットが更新されると、そのポートレットのすべてのコンシューマは即座に変更を自動的に受け取ります。図 2-3 に示すように、連合ポータル アーキテクチャの最も重大な利点は、ポータルの保守労力が非連合ポータルに比べて大幅に削減されることです。
次の節では、連合ポータル アーキテクチャを使用した場合の利点についてさらに詳しく説明します。
前の節で説明したように、連合によってポータルのデプロイメントと保守に大きな利点が得られます。この節では、次のトピックでこのような利点について詳しく説明します。
連合は、単なる新しい WebLogic Portal 機能にとどまりません。ポータル Web アプリケーション、特に中規模から大規模のポータル Web アプリケーションの開発者や管理者にとってはこれまでにないパラダイムと言えます。この新しいパラダイムの中核は、ポータルからポートレットを分離できる WSRP (Web Services for Remote Portlets) などの標準です。WSRP の詳細については、「WSRP とは」を参照してください。
ポータルのすべてのポートレットを 1 つのアプリケーションにバンドルするのではなく、リモート システムで実行される別々の Web アプリケーションに各ポートレットをデプロイし、WSRP を利用してそれらのポートレットを連合ポータルで使用できます。連合ポータルは、そのポートレットから切り離されているため、ポートレットを変更するたびにポータルを再デプロイする必要はありません。このように切り離されていることは、ほとんどの WebLogic Portal プロジェクトで、時間と費用の面でただちに大きな節約となって表れます。
ポータル連合の最も重要な利点は、「連合ポータルでは、リモート ポートレットが更新されても再デプロイする必要がない」ということでしょう。
標準ポータルの場合、すべてのポートレットは 1 つのエンタープライズ アプリケーションに組み込まれます。ポートレットを変更する場合、些細な変更であっても、エンタープライズ アプリケーション全体を再デプロイする必要があります。同様に、新しいポートレットの追加でも再デプロイが必要になります。通常、ポータルの再デプロイメントは、特に大規模なエンタープライズ ポータルの場合、テストとダウンタイムの費用が高く付きます。
連合ポータルの場合、リモート ポートレットは 1 つのエンタープライズ アプリケーションに組み込まれません。通常は、プロデューサというリモート システム上の別々の Web アプリケーションにデプロイされます。連合ポータルは、標準の WSRP (Web Services for Remote Portlet) や WSDL (Web Services Description Language) などを使用してこれらのポートレットを使用します。機能の追加や削除、バグ フィックスなど、ポートレットを変更すると、そのポートレットを参照するリモート ポートレットは自動的に変更を反映します。エンタープライズ ポータル アプリケーションを再デプロイする必要はありません。
連合ポータルは、プラグアンドプレイのサービス指向アーキテクチャの一例です。ほとんどの場合、ポータルの管理者は、開発者の協力を得なくてもリモート ポートレットを検索してそれをポータルに組み込むことができます。
連合ポータルのポートレットとその他のサービスは分散しているため、複数のチームがそれぞれ別々に新しい機能を開発してデプロイできます。連合していない場合、各チームは、サービス パックのリリースやソフトウェア ライブラリのバージョンなど、それぞれのデプロイメント スケジュールとソフトウェア コンフィグレーションを同期させる必要がありました。連合の場合は、このように緊密に結合する必要がなく、各チームはそれぞれで最適なソフトウェア ソリューションを自由に開発することができます。Web サービスのメカニズムを通して、連合ポータルの開発者はこれらの独立した開発チームが作成したソフトウェア リソースをそのまま使用できます。
ポータルの管理者は、プロデューサを検索して必要なポートレットを選択し、新しいリモート ポートレットをポータルに組み込むことができます。管理者の観点から、これらのリモート ポートレットは十分にテストされて使用できる状態にあります。コンシューマ ポータルの開発者や管理者には、コーディング、テスト、複雑なコンフィグレーションは必要ありません。
ポートレットが特定のソフトウェア ライブラリを使用する場合、管理が必要な強力な依存関係が存在します。ポートレットとライブラリのバージョンのいずれかが変更されると、既存のコードと互換性がなくなる場合があります。リモート ポートレットはリモート システムで開発、テスト、デプロイ、および実行されるため、リモート ポートレットを使用する連合ポータルはこのような依存関係から分離されます。
プロデューサを通して使用されるポートレットは、最小限の作業でいくつのコンシューマでも再利用することができ、新たにコーディングする必要もありません。先に説明したように、連合の場合は再利用しても統合、デプロイメント、コンフィグレーション、テストによるオーバヘッドが生じません。非連合の場合はこれらのオーバヘッドが生じます。
連合ポータルは結合がゆるく、標準をベースとしているため、WebLogic Portal でサードパーティ製のポートレットを使用することができます。同様に、WebLogic Portal にホストされているポートレットをサードパーティ製のポータルで使用することもできます。
  
|
