.NET webservice - quickly confirm, but continue processing in the background

Question

I am creating a .NET web service that will be consumed by a provider application, and I'm not sure how to do the following:

• The provider will call my webserivce with some information, but wants the confirmation to be returned quickly, simply stating that I received their information. They don’t care what I do with him and don’t want confirmation that I’ve finished processing.
• The information that I transmitted must do something behind the scenes and act with the information in a time-based manner, that is, take some action within a few minutes. I will contact a number of other web services, as well as work with some databases. Obviously, this will happen after I answer “Success” to the calling application.

I have no control over how the provider accesses my service, and the method they use to call it is synchronous, so I need to respond quickly so that the calling application continues its work. As I can see, there are two options, although I am open to others:

• Since the calling application is essentially sent to the queue, so that the process I wrote can process it, I can make the web service simply send the item to the database (or MSMQ or another queue) and then return success, the queue process will process from there.
• Ideally, I imagined that my service could return "Success", and then just continue processing on my own, but I'm not sure if this is possible. Since my processing is time sensitive, debugging the background processing of a new request is ideal, so the latency is minimal.

Are there any other ideas or is one of these sounds preferable?

Answer 1

I think 1st is the only possible solution. The second is a very poor design. Suppose that you process each request for 1 second, and on average 2 requests arrive on average in 1 second. You will quickly run out of resources (because more and more threads will be used)

The first is good, because you all control how you store and process requests. Good design is a web service as an interface that simply responds to Success and Queue requests. As a persistent repository, I recommend MSMQ or a database. Then create a service application that will have a thread pool and select from the queue (db).

Answer 2

• Get a request
• Drop the background process (for example, using BackgroundWorker) with the parameters passed
• Return confirmation - using a pointer or a similar request identifier
• Do your processing ...
  • At the same time, the caller can perform a ping service to update the state based on the identifier
  • While processing, return either the "still valid" answer, or if you are smart or can accurately predict it, return the measure of progress (possibly in the form of a percentage or remaining time)
• When processing is complete, return a Success message to the status request
• Make the solution available using the identifier with which you answered earlier

Answer 3

Option 1 is the way to go since the application already supports the queue.

As for option 2 - you can start the workflow from your web service, this will handle the work, and you can continue the “success” from the main thread.