私は、クライアントが静的ではないIPを持つファイアウォールの背後にあるクライアント/サービスプロジェクトを開発しています。クライアントはサービスを呼び出します。その後、サービスは、場合によっては数時間後に、クライアントのデータを取得したときにクライアントに連絡します。サービスごとに多くのクライアントが存在します。
私が見たいくつかのWCFサンプルは、接続を開いたままにしているように見えましたが、これはやりたくないです。いくつかのWFの例では、タイムアウトの期限が切れた後、おそらく別の接続で、サービスがクライアントに接続できるように見えました。
私はこれらのテクノロジーに非常に慣れていませんが、サンプルの調査とテストに数え切れないほどの時間を費やしてきました。読めば読むほど、最善の解決策についてはっきりしないようです。WFは私にとって最良の解決策でしょうか、それともWCFで希望する結果を達成することは可能ですか？
クライアントに連絡したいが、接続を開いたままにしない場合、クライアントは使用するエンドポイントを公開する必要があります。これは直接クライアントではない場合がありますが、クライアントに内部サーバーに登録してもらい、そのサーバーがエンドポイントを公開し、データを受信したときにクライアントに呼び出しをルーティングする場合があります。
ただし、エンドポイントをどこかに公開しない限り、クライアントに連絡することはできません。
それは理にかなっていますか？
WFとWCF また、WCFは、エンドポイントを公開および使用できる通信フレームワークであることに注意してください。WFは、WCFエンドポイントを介して自身を公開できるワークフローフレームワークです。これらは完全に異なるテクノロジーであり、一方は他方に依存しません。WFはWCFなしで実行できるためです。
より良い解決策は、このシナリオにキューを使用することです。ServiceBusを使用して、準備ができたときにクライアントが取得できるキューにメッセージを投稿します。MSMQを使用して同じことを行うこともできますし、データベースでさえキューとして機能することもできます。
WFはまだWCFを介して外界にさらされていることに注意してください。「数時間後」の側面を考慮すると、実際には2つの側面があります。クライアントとWCFサービス間のやり取りと、処理自体を実行するプロセス（数時間かかる部分）です。2つ目は、長いプロセスとしてWFで意味をなす場合があります。最初のものは、SignalRのようなフレームワークでより適切に処理される可能性があります。