WCFからNserviceBusにスワップする必要がありますか


13

さまざまな場所のクライアントネットワークにある多数のPCからメッセージを送受信する中央サーバーがあります。これを容易にするために、現在、証明書で保護された二重通信を使用して、TCPNetBindingsでWCFを使用しています。

現在、これにはいくつかの問題があります。主に、「切断モード」をサポートするように求められています(フォールトトレラントである必要があります)。私が知っていることから、WCFスタックを使用してこれを行う簡単な方法はありません-何かを実装し、おそらくmsmqを使用する必要があります。私は最近NServiceBusを見てきましたが、法案によく合っているように見えます-フォールトトレランス、シンプルなhttpゲートウェイなどを介してインターネット経由でメッセージを送信することができます。私はそれを調べることからその理由を見ることができます。

だから、私の質問は... NServiceBusを採用することは賢明なアイデアのように聞こえますか、またはこれに関連する他の提案/現実世界の経験がありますか?比較的あまり知られていない新しい技術を導入することや、セキュリティの確保、信頼できる方法ですべてをセットアップすること、途中で問題を起こすことなどの問題に直面することを心配していると思います。アーキテクチャにメッキを施し、WCFに固執してそれをうまく機能させるのではなく、実装で行き詰まってしまうような光沢のあるものを選択します。

ありがとう!


1
>「切断モード」をサポートします(フォールトトレラントである必要があります)クライアント側で多くのフォールトトレランスを構築する必要がありますか?サーバーでのMSMQのフォールトトレランスは、問題が発生した場合に状態を復元するのに最適ですが、選択した内容に関係なく、クライアントに大きな頭痛がすることは今でもわかります。
ブライアン

1
私がサポートする必要があるのは、クライアントがサーバーにメッセージを送信し、サーバーが最終的にそれを取得する「保証」です。したがって、オフラインの場合は、そこに到達するまで試行を続ける必要があります。NSBは、一方(と思う)WCFソリューションとして、「自由のための」何のコードが必要になること...
マット・ロバーツ

ブライアンにも部分的に同意します。MSMQは、最近のバージョンで適切に構成されている場合、キューとメッセージがそのように動作するように構成されている限り、すぐに使用できる切断モードを提供します。クライアントはメッセージをローカルの発信キューに保持し、サーバーがリモートキューで再び利用可能になったときに再送信できます。
ビル

WCFにはMSMQバインディングがあります...これを利用するいくつかの大規模な成功したアプリケーションについて、私は精通しています。そうは言っても、私はnServiceBusも好きですが、違うことをします。
カイルホジソン

回答:


12

これについて迅速に行う必要があり、WCFでの永続的な(切断された)操作を容易にするために簡単なものだけが必要な場合、WCF-MSMQバインディングを調べることをお勧めします。より大きな環境で何かが必要な場合は、nServiceBusをご覧ください。

私の考えでは、nServiceBusはより大きな分散環境で本当に輝き始めます。たとえば、次の例を考えてみてください(これは、WCFの場合は地獄ですが、nServiceBusの場合は簡単です)。

  • アプリサーバー層、キャッシュサーバー層、読み取り専用データベース層、読み取り/書き込みデータベース層で構成されるインフラストラクチャ
  • クライアントが新しいエントリを送信するたびに、これらのすべての層を一度に更新してほしい
  • WCFでは、各層レベルで個別のサービスを公開し、クライアントにそれらすべてにプッシュさせる必要があります(または、中央のオーケストレーションが同じことを行います)
  • nServiceBusでは、各層がこの情報のサブスクライバーになり、クライアントはそれを1回公開するため、サービスバスが残りを処理できます。

WCFにはMSMQバインディングがあります

ただし、主にWCFに固執する必要がある場合(短いタイムライン、他のWCF機能が必要)、MSDNでこの記事を確認することをお勧めします。MSMQのWCFバインディングの使用方法を示し、次に1つのサービスをHTTPからMSMQに移行する方法を示します。途中で、このシナリオの問題(およびこれらの問題の有用な解決策)の一部を示します。

これらの提案は両方ともMSMQを多用するため、Apache MQ、RabbitMQ、およびその他の一般的なキューイングシステムとは異なり、MSMQは一般的なブローカーベースのキューアーキテクチャではなく、分散キューです。つまり、WCFクライアントがキューをホストするリモートサーバーに接続できない間にMSMQトランスポートを介してメッセージを送信すると、クライアントマシンは、代わりに「送信キュー」と呼ばれる場所にメッセージをキューに入れます。メッセージは、クライアントのMSMQサービスがリモートMSMQサービスに再び接続できることを検出するまで、安全にそこに留まります。その時点で、メッセージはクライアントから最終宛先に流れます。

上記には少なくとも1つの注意事項があります。リモートサーバーが長時間オフラインの場合(MSMQのドキュメントを確認してください)、クライアントはメッセージを断念し、送信からデッドレターキューに移動します。デッドレターキューに転送されたメッセージは自動的に再送信できません。再構築する必要があります。

暗号化が必要でActiveDirectoryがない場合は、このブログエントリで、Sergey SorokinがActive DirectoryなしでWCFを使用してMSMQの通信を暗号化するために必要な手順を詳しく説明しています。


7

1対1の置き換えではありません。多くの場合、NServiceBusを使用して、WCFエンドポイントにメッセージをフィードしたり、WCFエンドポイントからメッセージを取得したりします。

いずれにせよ、このような非接続モードのシナリオの処理は、メッセージキューが本当に輝く場所です。NServiceBusは開始するのに適した場所です。他にも多くのオプションがあります。それらの多くは、実際には1日の終わりにMSMQをラップすることに注意してください。MSMQは非常に堅実なバックエンドであり、アクセス可能になったときに使用する価値があります。


ありがとう。私のWCF通信の大部分はこれらのPCとサーバー間の通信をサポートするためにあるので、私の場合は1:1の交換として見ていますが、nsbは私のためにこれをすべて処理しているようですので、それはスワップです-私のために。
マットロバーツ

Gotcha、それはあなたのためにかなりうまくいくはずです。
ワイアットバーネット
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.