How to architect this client/server application in .NET? [closed]

Question

We have a legacy 3rd party tool(developed in C/C++). The tool has a server component that runs a windows server which runs jobs(complex chained long database queries). It also has a client module that is installed on all users desktops and users will be able to add jobs, view running jobs and their progress, delete jobs i.e. basically manage the jobs. We want to develop such a tool in house using .NET technologies.

Currently we are thinking how to architect such a tool and appears like we are missing some critical pieces of the puzzle.

Client : We decided the client desktop application to be developed in WPF

Server : Currently we are thinking to develop it as console application but not quite sure how to architect it.

The main questions we have are

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 ?

How to push progress updates from server to the WPF clients when there is a change?

We are trying to do research how to do this but not finding any thing relevant to the topic. Any pointers to articles/guidance will be of great help.

Answer 1

The confusion you are having is in assuming that the execution of the job and the WCF endpoint are the same thing. I would split this up into three main items:

1. Client Application that has the UI elements for job management.
2. WCF service endpoint to retrieve job information and to send create/delete job requests.
3. Application that runs the jobs.

Client Application

The client application should retrieve the job data through the WCF service. You would supply screens for viewing executing jobs / create jobs / delete jobs / etc.

WCF Service

The WCF service would expose endpoints needed by the client application. This could include items such as: CreateJob, ViewJobs, DeleteJob, etc. The service should be reading/writing to your database backend.

Job Application

The job application would poll for New/Deleted jobs and perform whatever is necessary for the job to complete. It would update the job status in the database backend that the WCF service reads from. This could be a SQL Job, Windows Service, Console App., etc, (I'd probably make it a windows service since you probably want something that is running all the time to process jobs).

Questions

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?

By separating out the WCF Service from the application running the jobs this is negated. Note: You can have a console applications that hosts WCF and the job executer, but conceptually think of them as separate things (hosting in same console app is just an implementation detail).

How to push progress updates from server to the WPF clients when there is a change?

I wouldn't do this. I would have the UI either poll from time to time or provide a refresh button to retrieve the status through the WCF endpoint.

If you absolutely need to do this you need the Job executer to publish out messages as it runs the jobs and the client app would need to receive these messages (maybe MSMQ, Service Bus Implementation, BizTalk, etc).

Why do I prefer polling to server push

Now that I think about it there are probably cases where I would do push style, and some where I poll.

If I have many clients that are offsite (connecting through VPN or over the internet in general) I would have the clients poll as bandwidth and network latency are cost prohibitive. If the number of clients is high then every update message needs to be sent to every subscribing client. In this case I would tend to go to an ask don't tell model.

If the clients are in house and you need real time information streamed to them then the push model would make more sense. In this case you can clients connect to the server application and they can send messages back and forth over the connection (I have not personally done this so I have no recommendation on how to setup, hopefully something higher level than a socket).

If it's a situation where you want the messages as updates occur, but clients are located in many different places, then a pub/sub model might be best. In pub/sub the application would push update messages as they occur. The messaging system would check to see if there are any clients that are subscribing to the messages, and for all the clients that are subscribing the messaging system forwards a copy of the message to them. In your example a client would subscribe to job messages and the messaging system would send the updates to the location specified by the client (client needs a way to accept messages). NServiceBus, BizTalk are examples of this type of communication.