2

まず、これから説明する問題の有効な解決策がありますが、それは正しくないと感じています。

1 つのアプリケーション サーバーと約 30 ～ 100 のクライアントを持つアプリケーションがあります。サーバーのスケーリングは問題ではありません。最も重要なのはサーバーからクライアントへの通知ですが、もちろん、クライアントからサーバーに呼び出されるサービス メソッドもあります。

ここで行うことは、コールバック チャネルを使用してサービス コントラクトを作成し、サービスにクライアントを登録し (つまり、サービスにはアクティブなコールバック チャネルのリストが含まれます)、それらのコールバック チャネルを介して通知を送信することです。

ナビゲートする必要があった問題は次のとおりです。

  1. 接続のタイムアウト- サービスには、約 1 分ごとにクライアントによって ping される KeepAlive メソッドが含まれるようになりました。
  2. サーバーまたはネットワークの障害後にクライアントを再接続する- これが私が懸念している主なポイントです。現時点ではDuplexClientBase、サービスを呼び出すための長期実行クライアント オブジェクト (サービス参照、 から継承) と、受信した通知を処理するためのコールバック オブジェクトがあります。client.Faultedサーバーに再び到達できるようになるまで、クライアントとコールバック オブジェクトを新しく作成されたクライアントに置き換えようとします。このアプローチには、かなり奇妙な例外処理が含まれます...

質問:各クライアントで WCF サービスを開始し、各クライアントのエンドポイントをサーバーに登録したほうがよいでしょうか? 説明されている 2 つの問題に対するより良い解決策はありますか?

編集：要点：何か足りないのですか？- 説明されているアーキテクチャは非常に一般的であると信じており、それを行うための「デフォルト」の最良の方法を探しています。この種のセットアップのサンプルはありませんか?

4

1 に答える 1

3

問題が可用性（この場合はサービス->コンシューマーとコンシューマー->サービスの両方の可用性）に関するものである場合は、MSMQ（おそらくnetMsmqBindingを使用）のようなフォールトトレラントなトランスポートの使用を検討する必要があります。

複雑なWCFコールバックインフラストラクチャを、シンプルで耐久性のあるサブスクリプションストアに置き換えることができます。

「コールバック」を送信する必要がある場合は、サブスクリプションストアからコンシューマーのリストを取得し、それぞれにメッセージを送信するだけです。

ステートフル接続がないため、接続がタイムアウトすることはありません。

ネットワーク障害後の消費者からサービスへの再接続も解決されます。実際、小規模なネットワークの停止は目立たないでしょう。

申し訳ありませんが、これは元の質問に直接答えることはできません。この規模でのやり直しは、要件の範囲内にない可能性があります。

于 2012-04-05T07:53:04.403 に答える