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

StackOverflow https://stackoverflow.com/questions/640560

  •  22-07-2019
  •  | 
  •  

質問

最近、リモートポートレット用のWebサービスという新しい概念で心を広げました。またはWSRP。私は、職場での購入を検討しているJavaベースのWebポータルでのプレゼンテーションでそれを知りました。私たちは.NETショップであり、WSRPはこのポータルを拡張する手段となります。

製品を購入するかどうかについての最終決定を制御することはできませんが、WSRP準拠のポートレットを構築することがどれほど難しいかについての情報を提供できます。残念なことに、最近の件名へのクエリはほぼゼロになりました。

SOコミュニティの皆さん、次のことをお願いします。C＃/。NETでWSRP準拠のポートレットを構築するために、どのライブラリまたはフレームワークがありますか？一般にWSRPを使用する場合の長所と短所は何ですか？

ここには正解がないため、これをコミュニティWikiの投稿にします。

これまでのところ、私は次のものしか見つけていません。

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

役に立ちましたか？

解決

WSRP仕様を注意深く読むと、それがJava Portlet Specificationのリモートバージョンであることがわかります（その綴りが正しい場合）。これは、Javaポートレットの統合に役立つことを意味します。それ以外は、Javaポートレットのように見える必要がありますが、これはあまり一般的ではありません。

他のヒント

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

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

このものが今まで存在していたことは私を困惑させます。
解決しようとする問題は、多くの場合、解決する必要がある問題ではありません。

その人気/採用は、NetUnitからの最後のリリースが＆quot;この最新リリースではVisual Studio 2005と.NET 2.0のサポートが追加された＆quot;という事実によって推測できると思います。

私はCheesoに同意しなければなりません。 UIをデータと統合すると、ポートレットコンシューマのみにサービスが提供され、ポートレットプロデューサに大きな、不必要な、危険なレイヤーが追加されます。私たちの.NETショップは、最近WSRPを検討するように強制されました 、サポートと経験が不足していることがわかりました。私が議論した中で見た最高のMS中心のアプローチはこちら。しかし、特定のWCF実装/サポートは見つかりませんでした。リードは大歓迎です！

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

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

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

選択した数のポートレットのみが最もヒットしたときに、ポータルプラットフォーム全体の負荷を分散する必要がありますか？ポータルベンダーは、あなたがそう考えることを望んでいます。多くの場合、ポータルは、ポートレットが処理を完了するのを待つだけです。 WSRPを使用すると、ポータルプラットフォームに関係なくポートレットをロードバランシングする柔軟性が得られます。常に、最もヒットする数個のポートレットに分類されます。なぜそれらのポートレットだけの負荷分散を行わないのですか？したがって、80 CPUでポータルを不必要に負荷分散する代わりに、10 CPUでこれらの少数のポートレットを負荷分散できます。 WSRPはクラウドコンピューティングにも最適です。

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

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top