アプリケーション間の通信（プロセス間）？

Question

「サーバー」を作成しようとしています。外部ハードウェアと通信する責任があるアプリケーション。アプリケーションは、クライアントからの要求を処理します。クライアントはサーバーにメッセージを送信し、サーバーがハードウェアの処理で忙しい場合、新しいメッセージは後で処理されるキューに保存されます。

クライアントは、リクエストをキャンセルすることもできます（サーバーのキューにある場合）。サーバーアプリケーションがハードウェアで終了すると、ジョブをリクエストしたクライアントに結果を送り返すことができます。

サーバーアプリケーションとクライアントアプリケーションは、同じPC上にある場合とない場合があります。 すべての開発は.NET（C＃）2005で行われます。

だから、私の質問は次のとおりです。このコミュニケーションの問題を解決する最良の方法は何ですか？

MSMQ？石鹸？ WCF？リモーティング？その他？

Answer 1

リモート処理

すべての開発が.NET 2005で行われる場合、リモーティングが最善の方法です。 http://en.wikipedia.org/wiki/.NET_Remoting

Answer 2

.NET 3.0以降を使用できると仮定すると、おそらく通信チャネルとしてWCFを使用します-インターフェイスは一貫していますが、クライアントとサーバーがそれぞれに関連する場所に応じて適切なトランスポートメカニズムを使用できますその他-必要に応じて、SOAP、MSMQ、またはバイナリ形式などを使用することを選択できます（必要に応じて独自のロールを作成できます）。また、双方向通信の必要性もカバーしています。

サーバーでのメッセージのキューイングは、おそらくキューに入れられたメッセージを削除する必要があることを考えると、おそらく別の問題と見なされるべきです。

Answer 3

クライアントとサーバーのプロセスが同じマシン上にある場合、名前付きパイプを使用すると、生のバイト転送速度が最速になると思います。 プロセスが異なるマシンにまたがっている場合、ソケットベースのアプローチを使用する必要があります。

リモート処理は非常に遅いと報告されています。ソリューションの展開を計画しているターゲットOSに基づいて、WCF et.allなどのオプションを使用できますが、これらのプロトコルのオーバーヘッドは、決定する際に確認する必要があるものです。

Answer 4

MSMQはある程度意味がありますが、セキュリティと展開に関する考慮事項があります。サービスバス（NServiceBusやMassTransitなど）を調べることができます。また、役立つSQL Server Service Brokerもあります（また、トランスポートとしてサービスバスで使用することもできます）。

WCFは別の見方ですが、それは実際にネットワーク間トランスポートであるため、おそらくWCF呼び出しでサーバーキューにメッセージを書き込む必要があります。

リモーティングはお勧めしません。懸念の分離を維持するのが難しく、気付く前に気付かないうちに本当におしゃべりなインターフェイスを開発しているからです。リモート呼び出しは相対的なコストが高いため、メッセージをかなり粗くするようにしてください。 WCFが私の推奨です。特に、HTTPトランスポートを使用するように設定でき、多くの展開とセキュリティの頭痛を回避できるためです。

Answer 5

。たとえば、XML WebサービスはHTTPプロトコルとXMLを使用するSOAPフォーマットの共通インフラストラクチャ上に構築されるため、インターネットの成長によりXML Webサービスは魅力的な通信方法になりました。これらは公的な標準であり、追加のプロキシまたはファイアウォールの問題を心配することなく、現在のWebインフラストラクチャですぐに使用できます。

ただし、HTTP接続を介したSOAPシリアル化の使用に関連するパフォーマンスの問題のためだけに、すべてのアプリケーションを何らかの形式のXML Webサービスを使用して構築する必要はありません。

.NETでの通信オプションの選択アプリケーションに必要なオブジェクト間通信の形式を決定するのに役立ちます。