WSRP は基本的に、ポータルからポートレットへの Web サービス標準です。ポータルとポートレットの間で交換される主要なデータは何ですか? これはマークアップであり、主にほとんどのポータルが Web UI を使用しているためです。純粋なデータ対 UI ではないというこの全体的な考えは、議論の余地があります。これは、ポートレットの検出、メタ データ、マークアップ、対話、キャッシング、ポートレット間の通信などのための Web サービスを意図しています。WSRP でなくても、ポータルはそれを行います。ただし、WSRP はオープンなクロス プラットフォームの標準です。
独自の製品やプラットフォームのポートレットのみを統合するポータルとは? Java ベースの PeopleSoft HR を取得し、SharePoint から従業員にポートレットへのアクセスを提供したいと考えていますか? 幸運を。これがほとんどのエンタープライズ ソフトウェアにとって実現可能なシナリオではないのはなぜですか? はい、UI に関連する統合であることは認識しています。これが、私がポータルを使用している主な理由の 1 つです。「純粋な」データ レベルで PeopleSoft を SharePoint に統合すると、どういうわけか従業員福利厚生 Web パーツが魔法のように SharePoint に表示され、すぐに使用できるようになるとは期待していません。ただし、ポートレット間の統合が WSRP に基づいている場合、それは私が期待することです。
WSRP は完璧ではありませんが、私の意見では優れたソリューションです。ポータル内にポートレットを簡単に統合できるだけでなく、ポータルをアプリケーションから分離します。バイナリをポータル サーバーにデプロイしたり、同じサーバー上で実行したりする必要はありません。意味あり。ポータル サーバーと同じサーバー上でアプリケーションを実行しないでください。どちらもアップグレードされません。アプリケーション バイナリをポータル サーバーと同じサーバーに配置するのは正気ではないという結論に達しました。「このアプリケーションをポータル サーバーにデプロイして、セキュリティ、安定性、パフォーマンス、およびその間のすべてに影響を与えてください。できるだけ多くの依存関係を作成し、アプリケーションをアップグレードするたびにポータル サーバー全体を停止させたいと思います。」それは依存の悪夢です。
選択した数のポートレットのみが最もヒットする場合に、ポータル プラットフォーム全体の負荷を分散する必要がありますか? ポータル ベンダーは、そう考えてほしいと考えています。多くの場合、ポータルはポートレットの処理が完了するのを待っているだけです。WSRP を使用すると、ポータル プラットフォームとは別に、ポートレットの負荷を柔軟に分散できます。これは常に、最も多くヒットするいくつかのポートレットに分類されます。それらのポートレットだけを負荷分散しないのはなぜですか? したがって、80 CPU でポータルを不必要にロード バランシングする代わりに、これらの少数のポートレットを 10 CPU でロード バランシングすることができます。WSRP は、クラウド コンピューティングにも最適です。
WSRP は、ポータルからポートレットへの標準です。複数のポータルで動作し、複数のプラットフォームで動作する可能性のあるポートレットを作成する場合は、WSRP が最適です。サード パーティのポートレットの統合をリモートで検討している場合は、WSRP が最適です。唯一の基準です。ただし、他の独自のローカル ポータルからポートレットへのインターフェイスよりも大きな利点がいくつかあるため、それらの利点についても考慮する必要があります。