CODEWITHSUNDEEP
c#asp.netwcfarchitecturewindows-services
bp581
bp581

Reputation: 869

ASP.Net Architecture solution/suggestion

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

  1. ASP.Net web application calling a WCF to perform task.

  2. WCF intern triggers a running windows service to perform the task. Windows service intern opens multiple threads to perform the task.

  3. Windows service updates the database with progress status on task and Web application reads the status updates to user. Web application is developed by separate team while other team takes the responsibility of WCF and Windows service.

The reason for developing windows service instead of just WCF is due to the need of opening multiple threads as part of task completion. Since WCF can be used only as fire and forget from web application, other team made a decision of using the windows service. Also as (as per other teams research) its not possible to close all threads while exiting a task in WCF.

  1. Is this a good architecture?.
  2. Is it OK to call windows service to perform the task from WCF?
  3. Is it possible to architect this application without using windows service ?.

Upvotes: 3

Views: 553

Answers (1)

tom redfern
tom redfern

Reputation: 31780

Is this a good architecture?

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

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

Is it OK to call windows service to perform the task from WCF?

There's nothing technically un-OK about this, but you might as well just host your WCF service within a windows service instead of having them separate. Just another moving part for no real gain.

Is it possible to architect this application without using windows service ?

See above.

From comments:

Unfortunately the task that gets initiated from asp.net application might go on from 10 minutes to 1+ hr

Some of our background tasks take in excess of 30 minutes, though none are taking an hour yet. While there's no guarantee that an IIS worker thread is going to hang around long enough to fulfill the job, hangfire provides an iron-clad guarantee that jobs which are inadvertently unloaded will be re-run and will succeed eventually. This is automatic and requires no extra config.

also user needs to get status update on progress of the task.

As I said in my original answer, we are providing status indications (job type, time elapsed, expected finish time, etc) in real-ish time via client side polling. We actually poll the hangfire database (not the recommended approach but safe enough for us), but you can also hit the hangfire job manager in memory to retrieve this information (this is the recommended approach).

Looks like HangFire is more like fire and forget

Hangfire is definitely fire and forget, but that's what makes it robust, and should be a feature of any background task runner implementation. Waiting around for some kind of completion callback event is tricky and unpleasant in my opinion.

Upvotes: 3

Related Questions