1

これは多くの質問がありますが、私はより具体的な答えを求めています。

私は、エージェントおよびマネージャーとの通信に依存する一連のアプリケーションを設計/開発しています。コマンド(マネージャーからエージェントへ)と統計(エージェントからマネージャーへ)を通信します。現時点では、このアプリケーションスイートはWindowsプラットフォームでのみ実行されますが、最終的には他のシステムにスケールアウトする必要があります。このアプリケーションが使用される場所によっては、システム全体に大量のアプリケーションをインストールしたくない場合や、マネージャー側がそこに座ってジュースを吸い上げたくない場合(分析!)、したがってクラウドに配置したい場合があります。

ですから、私は.Net TCPソケットを使用できることを知っています。これは、優れたrawパフォーマンスを備えているようで、非常に柔軟性があります。

また、Windows Communication Foundationを使用できることも知っています。これは、当然のことながら、より良い選択のようです。

しかし、コマンドを送信して統計を受信して​​いるので、Powershellを使用してリモートで接続し、サーバーとなるサーバーから利用できる多数のコマンドを使用して、クライアントアプリケーションの作成を完全に停止することができます。

これらのアプリケーション(特にクライアント)は、ただそこに座って、静かに、仕事をし、一般的な操作に干渉しないようにする必要があることを念頭に置いて、どちらが良いと思いますか?

さらに詳しい説明が必要な場合は、喜んでお知らせします。

ありがとう。

4

2 に答える 2

1

それらは、コマンド(サーバーからクライアントへ)と統計(クライアントからサーバーへ)を通信します。現時点では、このアプリケーションスイートはWindowsプラットフォームでのみ実行されますが、最終的には他のシステムにスケールアウトする必要があります。

説明には、PowerShellと互換性のない要件が1つあります。PowerShellはWindowsの世界でのみ機能します。

WCFサービスは、適切に構成されていれば、リソースを消費しないはずです。IISとWASは、サービスをオンデマンドでロードし(クライアントからの要求を取得すると)、不要な場合はアンロードできます。

http://blogs.msdn.com/b/blambert/archive/2009/02/13/enable-iis.aspx

http://msdn.microsoft.com/en-us/library/ms731053.aspx

TCPソケットはパフォーマンスの観点からは最高ですが、残念ながら、実装には、WCFに既に存在するすべての配管を実装するために多くの追加のDEVおよびQA作業が必要になります。その作業を終えると、業界標準と互換性のないもう1つの「自転車」ができあがります。

私の投票はWCFです。

于 2012-06-03T19:40:02.580 に答える
1
于 2012-06-03T19:40:16.933 に答える