C＃/ .NETのリモートポートレット用Webサービス - オプション？

Question

私は最近、新しいコンセプト、つまりWeb Services for Remote PortletsまたはWSRPによって私の心を広げました。私たちは、仕事中に購入を検討しているJavaベースのWebポータルのプレゼンテーション中にそのことを知りました。私たちは.NETのショップであり、WSRPはこのポータルを拡張する手段になります。

私たちが製品を購入するかどうかの最終決定を制御することはできませんが、WSRP準拠のポートレットを構築することがどれほど難しいかについての情報を提供することができます。残念ながら、私の最近の主題への照会はほとんど無くなりました。

C＃/ .NETでWSRP準拠のポートレットを構築するためのライブラリやフレームワークはありますか？一般的にWSRPを使用する際の長所と短所は何ですか？

ここに正解がないので、私はこれをコミュニティのwiki投稿にします。マイクロソフトで

• WSRP Toolkit for Sharepoint（しかし、Sharepointのを必要とする）：

  はこれまでのところ、私は次のことを発見しました。

• WSRP Portal and WSRP .NET Framework NetUnityによる。

WSRPがSOAPの上にあるとすれば、これはWCFバインディングとチャネルの完璧な候補のように思えますが、私はその件に関して何も見ません。

Answer 1

WSRP仕様を慎重に読んだら、それはJavaポートレット仕様のリモートバージョンであることがわかります（私がそのようなことをしている場合）。つまり、Javaポートレットを統合するのに便利です。他のものは、あまり一般的ではないJavaポートレットのように見える必要があります。

Answer 2

NetUnitの最新リリースは「この最新リリースではVisual Studio 2005と.NET 2.0のサポートが追加された」ということで、その人気/採用が推測できます。

Answer 3

WSRPは非常に対照的です。今や世界は、データモデルとプレゼンテーションモデルとの密接な結合が最適ではないことを認識しています。 RSS、REST、MVC、およびWebサービスの成功は、これを一般的に示しています。 WSRPはその名前にもかかわらず、Webサービスのコア原則に反するものです。 WSRPの仕様では、データとプレゼンテーションを別々に保つための健全なアドバイスは無視され、密接に結合されています。

WSRPは、UIレベルでの統合を約束します。これは解決しなければならない間違った問題のようです。

これは、このことがある限り私にはわかりません。
解決しようとする問題は、多くの場合、がに解決されるべき問題ではありません。

Answer 4

私はCheesoに同意する必要があります。 UIとデータを統合するのは、ポートレットのコンシューマーにのみ役立ち、ポートレットのプロデューサーには、大きくて不要な危険なレイヤーが追加されます。私たちの.NETショップは最近となっており、WSRPを検討するのにと私はサポートと経験が不足しています。私が議論してきた最良のMS中心アプローチはhereです。しかし、特定のWCF実装/サポートが見つかりませんでした。すべてのリードは非常に感謝！

Answer 5

WSRPは基本的に、ポータルからポートレットへのWebサービス標準です。ポータルとポートレットの間で交換される主要なデータは何ですか？これはマークアップであり、主にほとんどのポータルがWeb UIを使用しているためです。純粋なデータではなく、UIではないというこの考えは、間違いです。これは、ポートレットの発見、メタデータ、マークアップ、インタラクション、キャッシュ、ポートレットとポートレットの通信などのWebサービスを意味します。これはWSRPでなくてもポータルが行うことです。 WSRPはオープンなクロスプラットフォーム標準です。

ポートレットを独自の製品やプラットフォームから統合するポータルとは何ですか？ JavaベースのPeopleSoft HRを入手し、SharePointから従業員にポートレットへのアクセスを提供したいと考えていますか？がんばろう。なぜこれはほとんどのエンタープライズソフトウェアにとって達成可能なシナリオではありませんか？そして、はい、私はそれがUIに関連する統合であることを認識します。それが私がポータルを使用している主な理由の1つです。 PeopleSoftをSharePointと「純粋な」データレベルで統合することを期待しているようではなく、何らかの形でEmployee Benefits Web PartがSharePointで魔法のように使用可能にポップアップしているようなものではありません。しかし、これは、ポートレットとポートレットの統合がWSRPに基づいている場合に期待されるものです。

WSRPは完璧ではありませんが、私の意見では優れた解決策です。ポータル内でのポートレットの簡単な統合のほかに、ポータルはアプリケーションから分離されます。ポータルサーバーへのバイナリの展開や、同じサーバー上でのバイナリの展開はありません。意味あり。ポータルサーバーと同じサーバー上でアプリケーションを実行しないでください。どちらもアップグレードされません。アプリケーションバイナリをポータルサーバと同じサーバに置くのは難しいという結論に至りました。 「このアプリケーションをポータルサーバーに展開して、セキュリティ、安定性、パフォーマンス、およびそれらの間のすべてに影響を与え、できるだけ多くの依存関係を作成し、アプリケーションをアップグレードするたびにポータルサーバー全体を停止したい」それは依存の悪夢だ。いくつかのポータルベンダーのコンサルタントを得て、アップグレードするときに手を携えて、誰かに責任を負わせるようにしましょう。

選択された数のポートレットだけがヒットした場合、ポータルプラットフォーム全体の負荷を分散する必要がありますか？ポータルベンダーはあなたにそう思うでしょう。多くの場合、ポータルは処理を完了するためにポートレットで待機する以外に何もしません。 WSRPを使用すると、ポータルプラットフォームとは独立してポートレットをロードバランスする柔軟性が得られます。常にヒットしたポートレットに分解されます。これらのポートレットのみの負荷を分散するのはなぜですか？そのため、ポータルを80 CPUで不必要にロード・バランシングする代わりに、それらのポートレットを10個のCPUにロード・バランスさせることができます。 WSRPはクラウドコンピューティングにも絶対に最適です。

WSRPは、ポータルからポートレットへの標準です。複数のポータルで、また複数のプラットフォームで動作するポートレットを作成する場合は、WSRPを使用します。サードパーティのポートレットを統合することを遠隔から検討している場合は、WSRPがそれです。それは唯一の基準です。ただし、他の独自のローカルポータルからポートレットへのインタフェースに比べていくつかの重要な利点もあります。これらの利点についても考慮する必要があります。