Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Separate executable vs. background thread

Status
Not open for further replies.

PGO01

Programmer
Jan 8, 2008
156
GB
I have inherited a system - in which part of it works like this:

User submits a request -->
Web service is called on the server -->
The web service does some processing and then kicks off a separate process (an executable) to do some time-consuming tasks -->
the web service then tells a Windows service that the process has begun -->
This Windows service then checks every few seconds to see if the executable has finished its task (a flag on the DB) -->
When the relevant flag in the database is set, the windows service does some other stuff.

Would it be better to have the time-consuming stuff all done in the web service - in a background thread, and have the thread callback when it has finished?

If this is the route to go - is it worth changing an existing system that 'works'.

Opinions appreciated.
 
It all depends on what that executable is supposed to do. But, the whole set-up sounds fishy.

Still, "If it's not broken, don't fix it", especially if it does it in a performant and managable way.

Perhaps you can gradually incorporate the executable's logic into the webservice and make it obsolete over time. Unless you get the budget to do it, but typically something has to go horribly wrong, before that happens :).
 
The theory of what they want makes sense. have the UI notify a process to start and then allow the user to continue using the system. meanwhile the actual work is done offline. the work consists of separate operations. as one component completes (db flag) another is started.

The implementation seems overly complex though. there are a lot of disconnected parts which can be brought together to simply the complexity. On the one hand I agree with kristof' if it ain't broken don't fix it. On the other hand broken windows can destroy a system.

I would approach the offline work differently like this. There would be a front end (web) and backend(windows service). i would use a message bus to send messages from the UI to the windows service. The service would receive the message and process all the work that needs to be done. depending on the complexity of the operation I may need to use the concept of a saga to manage the state of the work flow, but that's just an implementation detail.

if you decide to migrate to a service bus there are 3 well known frameworks to choose from. NServiceBus, Mass Transit & Rhino.ServiceBus. All three have an active development community and really good help forums.

Jason Meckley
Programmer
Specialty Bakers, Inc.

faq855-7190
faq732-7259
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top