Clever Geek Handbook

ASP.NET Architectural Solution

We have 3 components as part of our application architecture; ASP.Net Web, WCF Service and Windows Service.

  • ASP.Net web application calling WCF to complete a task.

  • WCF intern starts a running Windows service to complete the task. The Windows service worker opens multiple threads to complete the task.

  • The Windows service updates the database with the task's execution status, and the web application reads the status updates to the user. The web application is developed by a separate team, and another team takes responsibility for running WCF and Windows.

The reason for designing a Windows service instead of WCF is due to the need to open multiple threads as part of the task completion. Since WCF can only be used like fire and forget from a web application, another team decided to use a Windows service. Also, as with other commands, it is not possible to close all threads when exiting a task in WCF.

  • Is this good architecture?
  • Is it possible to call a Windows service to perform a task from WCF?
  • Is it possible to create this application without using a Windows service?
+3


source to share


1 answer


Is this good architecture?

Agree with other commenters, you can do your whole solution in ASP.NET using something like hangfire to handle background tasks.

I've used this framework in my current project to handle various types of long running tasks, and it's solid, especially when combined with some kind of client side notification library like angular toasty to indicate the status of background tasks.

Is it possible to call a Windows service to perform a task from WCF?

There is nothing technically out of place with this, but you can simply host your WCF service in a Windows service instead of having them separately. Another moving part with no real payoff.

Can I archive this application without using windows? service?

See above.



From comments:

Unfortunately, a task initiated by an asp.net application can take anywhere from 10 minutes to 1+ hours

Some of our background tasks take more than 30 minutes, although none of them take another hour. While there is no guarantee that an IIS worker thread will run long enough to get the job done, hangfire provides an iron-guaranteed guarantee that jobs that are unintentionally unloaded will be restarted and ultimately successful. This is automatic and does not require any additional configuration.

also, the user needs to get an update status about the progress of the task.

As I said in my original answer, we provide status readings (job type, elapsed time, expected end time, etc.) in real time via client side polling. We actually polled the hangfire database (not the recommended approach, but safe enough for us), but you can also go to the memory job manager to get this information (this is the recommended approach).

Looks like HangFire is more like fire and forgets

Hangfire is definitely fire and forget, but that makes it robust and should be a feature of any running background job implementation. In my opinion, waiting around some kind of completion callback event is tricky and frustrating.

+3


source






More articles:


All Articles