混乱しているのは、ジョブの実行と WCF エンドポイントが同じであると想定していることです。これを 3 つの主な項目に分けます。
- ジョブ管理用の UI 要素を持つクライアント アプリケーション。
- ジョブ情報を取得し、ジョブの作成/削除要求を送信するための WCF サービス エンドポイント。
- ジョブを実行するアプリケーション。
クライアント アプリケーション
クライアント アプリケーションは、WCF サービスを介してジョブ データを取得する必要があります。実行中のジョブの表示/ジョブの作成/ジョブの削除などの画面を提供します。
WCF サービス
WCF サービスは、クライアント アプリケーションが必要とするエンドポイントを公開します。これには、CreateJob、ViewJobs、DeleteJob などの項目が含まれる可能性があります。サービスは、データベース バックエンドに対して読み取り/書き込みを行う必要があります。
求人応募
ジョブ アプリケーションは、新規/削除されたジョブをポーリングし、ジョブを完了するために必要なことは何でも実行します。WCF サービスが読み取るデータベース バックエンドのジョブ ステータスを更新します。これは、SQL ジョブ、Windows サービス、コンソール アプリなどである可能性があります (ジョブを処理するために常に実行されているものが必要になるため、おそらく Windows サービスにするでしょう)。
質問
How can a server console application expose ASMX or WCF web services(so that WPF clients get the status of the jobs) WHILE CONTINUING TO RUN THE JOBS?
ジョブを実行するアプリケーションから WCF サービスを分離することで、これは無効になります。注: WCF とジョブ実行プログラムをホストするコンソール アプリケーションを使用できますが、概念的にはそれらを別のものと考えてください (同じコンソール アプリでのホスティングは実装の詳細にすぎません)。
How to push progress updates from server to the WPF clients when there is a change?
私はこれをしません。UI を時々ポーリングするか、WCF エンドポイントを介してステータスを取得するための更新ボタンを提供します。
絶対にこれを行う必要がある場合は、ジョブ実行者がジョブを実行するときにメッセージを発行する必要があり、クライアント アプリはこれらのメッセージを受信する必要があります (MSMQ、サービス バスの実装、BizTalk など)。
サーバープッシュよりもポーリングを好む理由
そういえばプッシュ型もあるし、ポーリング型もあると思います。
多くのクライアントがオフサイトにある場合 (一般的に VPN 経由またはインターネット経由で接続している)、帯域幅とネットワークの待ち時間が法外なコストになるため、クライアントにポーリングさせます。クライアントの数が多い場合、すべての更新メッセージをすべてのサブスクライブ クライアントに送信する必要があります。この場合、私はモデルを言わないで尋ねる傾向があります。
クライアントが社内にいて、リアルタイムで情報をストリーミングする必要がある場合は、プッシュ モデルの方が理にかなっています。この場合、クライアントはサーバーアプリケーションに接続でき、接続を介してメッセージを送受信できます (私は個人的にこれを行っていないため、セットアップ方法に関する推奨事項はありません。うまくいけば、ソケットよりも高いレベルのものです)。
更新が発生したときにメッセージが必要な状況であるが、クライアントがさまざまな場所に配置されている場合は、pub/sub モデルが最適な場合があります。pub/sub では、アプリケーションは更新メッセージが発生するとプッシュします。メッセージング システムは、メッセージをサブスクライブしているクライアントがあるかどうかを確認し、サブスクライブしているすべてのクライアントについて、メッセージのコピーをそれらのクライアントに転送します。あなたの例では、クライアントはsubscribeメッセージを処理し、メッセージング システムはクライアントによって指定された場所に更新を送信します (クライアントはメッセージを受け入れる方法が必要です)。NServiceBus、BizTalk は、このタイプの通信の例です。