views:

29

answers:

2

I am developing an Application where I am submitting POST Requests to a .NET Web Service.

Current implementation is to process the request instantly and give response. In actual deployment, there will be huge amount of data that needs to be processed and thus the request must be processed offline.

What are the strategies that can have the task accomplished

Should I implement a Windows Service, or a scheduled task that invokes an application to perform the desired task.

+4  A: 

This might be a good case for MSMQ. Your webservice can fill the queue with incoming data, and another process can read those messages and perform the necessary processing.

Here's a good overview of MSMQ:

http://www.primaryobjects.com/CMS/Article77.aspx

Dave Swersky
+1 for a solution using built-in technology.
Nate Bross
+2  A: 

If you have so much data it cannot be processed in real-time, I would probably setup the service to do the following:

ProcessRecordViaPost

  1. Create new record in "Queue" database with UniqueID, and all other info to be processed
  2. Return UniqueID to client immediatly

ReadRecordViaGet

  1. Check queue, if processed return data if not return status code (number of items in queue before it?)

I would also have a windows service that continually grabs the oldest item from the Queue, and processes it and moves on to the next oldest.

Nate Bross
Since the service will continually grab data, it's not wise to keep the requests on a database right? So, is it best to use MSMQ for storing the requests.
Gunner
If they are only going to be processed and deleted, then yeah, a database would be overkill. However, since you aren't passing data back immediatly, how will your web service return data when the user finally comes back for it? It seems like you need to store the queue at least until the user makes the second request, no?
Nate Bross
@Nat Bross: There will not be any second request. The user will be notified through email.
Gunner