これが私が必要とするデザインです:私のデザインのアイデア。
「サブスクライバー」のデザインは、サービスの「オレンジ」の部分に適していますか?
クライアントは、「読み取り」操作と「書き込み」操作を実行するためにサービスに接続する必要があり、サービスから (PUSH 方式で) 通知を取得する必要もあります。
最初は、「読み取り」および「書き込み」機能を提供するサービスも (バックグラウンド スレッドを介して) 通知を送信できると考えていましたが、「CallBack」はサービスが呼び出す必要がある場合にのみ使用されることを理解しました。クライアントの要求に対する応答としてクライアント上で機能します。つまり、サービスはクライアントへの呼び出しを開始できません。では、「Subsciber」の設計はこれで正しい方法ですか?
つまり、短い答えはイエスです。パブリッシュ/サブスクライブ パターンの使用は非常によく知られているモデルです。消費者をパブリッシャーから切り離すのに役立ちます。悪魔は、実装の詳細と、どれだけの複雑さを処理できるか、および設計で何を犠牲にするかです。
トレードオフ (WCF クライアントである必要があり、クライアントとサービスを所有している必要があります) と制限 (直接結合されたクライアント、ネットワーク トポロジの制限) を受け入れたい場合は、WCF二重チャネルの実装から始めることができます。
二重チャネルの制限が気に入らない場合は、MSMQ やNServiceBusなどを使用して、pub/sub 要件を容易にすることを検討できます。Windows Azure AppFabric Service Busを使用すると、次のレベルに進むことができます。
Duplex は、クライアントからの呼び出しが到着したときだけでなく、独立してクライアントにメッセージを送信できます。
デュプレックスは耐久性がありません。クライアントが離れたり、通信に問題が発生したりしたときに、チャネル障害から回復する必要があります。デュプレックスの保護は難しい場合があります。両側に WCF クライアント/サービスが必要です。ネットワーク トポロジに注意する必要があります。
2 つの異なるバインドされたコンテキスト (システム) があります。1 つはクライアントがコマンドとクエリを送信するためのもので、もう 1 つはこれらのイベントをリッスンしたい人に興味深いイベントを公開するためのものです。
編集 - 一部のクライアントが iOS デバイスの場合はどうなりますか? DUPLEX を使用すると問題が発生しますか? DUPLEX チャネル経由で WCF サービスと通信する iOS アプリを開発できますか?
回答: iPhone で SO WCF デュプレックス接続が表示されますか? 相互運用可能な WCF Web サービスを開発する際に知っておくべきことは何ですか?
